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can  be  assessed,  and  logistics  can  be  played.  The  model  recogilzes 
severed  lines  of  retreat  and  lines  of  supply  and  imposes  appropriate 
consequences.  The  documentation  consists  of  three  volumes:  (1)  A 
Guide  for  Potential  Users;  (2)  Game  Designer's  Manual;  (3)  Player’s 
Manual. 
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PREFACE 


IDAHEX  is  a computerized  model  of  conventional  land 
warfare  at  the  theater  level.  Its  documentation  consists  of: 


Volume  1 
Volume  2 
Volume  3 


A Guide  for  Potential  Users 
Game  Designer's  Manual 
Player's  Manual 


Volume  1 outlines  the  model's  fundamental  characteristics. 
Volume  2 (this  volume)  comprehensively  describes  the  model  and 
its  data  base.  Volume  3 contains  enough  information  for  some- 
one with  a modest  knowledge  of  land  warfare  to  play  an  IDAHEX 
game.  It  outlines  the  entire  model,  identifies  information 
the  game  designer  should  give  the  players,  and  describes  IDAHEX 
as  a war  game  from  the  players'  perspective. 


Comments  and  inquiries  are  welcomed, 
to  the  author  (telephone:  703-558-1874). 
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1.  UNDERSTANDING  THE  MANUAL 


IDAHEX  is  a model  of  warfare.  The  model  has  been 
Implemented  as  a computer  program,  written  in  FORTRAN.  Usually, 
no  distinction  is  drawn  between  the  model  and  the  program;  this 
manual  refers  to  both  as  "IDAHEX". 

As  a model,  IDAHEX  imposes  some  structure:  there  are 
exactly  two  sides  in  the  conflict,  "Red"  and  "Blue";  each  side's 
force  consists  of  individual  "battle  units";  the  postures  that 
a battle  unit  can  assume  are  organized  into  rigidly  sequenced 
classes;  the  area  on  which  the  Red  and  Blue  forces  move  and 
fight,  termed  the  "area  of  war",  is  approximately  rectangular 
and  is  partitioned  into  regular  hexagons;  each  battle  unit's 
location  is  identified  with  a hexagon.  Within  this  structure 
the  "game  designer"  creates  a game.  He  specifies  the  compo- 
sitions of  the  Red  and  Blue  forces,  the  resources  held  by  each 
battle  unit,  the  postures  battle  units  can  assume,  the  battle 
units'  mobility,  their  resources'  effectiveness  in  combat, 
the  terrain  of  the  area  of  war,  and  the  size  of  the  hexagons. 
Loosely  speaking,  the  model  is  a war  game  whose  rules  are  param- 
eterized; the  game  designer  sets  the  parameters,  turning  a gen- 
eral structure  into  a specific  game.  As  a tool  for  designing 
war  games,  IDAHEX  is  valuable  because: 

(1)  it  is  systematic,  and  therefore  protects  against 
design  errors  and  omissions; 

(2)  it  incorporates  reasonably  sophisticated  procedures 
for  assessing  movement,  combat,  air  support,  and 
supplies  consumption,  obviating  the  time-consuming 
alternatives  of  writing  ad  hoc  computer  programs  and 
making  the  assessments  manually; 

(3)  it  contains  extensive  logic  for  handling  the 
consequences  of  maneuver. 

The  last  point  deserves  emphasis.  If  a model  plays  maneuver  at 
all — i.e.,  if  battle  units  can  move  in  more  than  one  dimension — 
engagements  may  start  and  stop,  battle  units  may  be  attacked 
from  multiple  directions,  attackers  may  be  attacked  from  the 
flank  or  rear,  and  enemy  units  may  meet  on  the  march.  IDAHEX  can 
handle  these  events.  Without  that  capability,  the  game  designer 
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would  have  to  rely  on  a control  team  to  make  ad  hoc  Judgments 
or  would  have  to  write  a web  of  rules. 

^Thls  manual  describes  the  IDAHEX  model  and  shows  how  to  use 
IDAHEX  to  design  a war  game.  The  Glossary  briefly  defines  all 
variables  input  by  the  game  designer  as  well  as  variables  and 
functions  used  internally  by  the  IDAHEX  computer  program.  De- 
tailed Information  on  almost  any  variable  or  function  in  the 
Glossary  can  be  found  through  the  Index.  Some  variables  and 
funct ionsn-easily  identified  because  their  names  appear  in 
brackets-^o  not  actually  exist  in  the  IDAHEX  program  but  should 
be  treated  just  as  any  other  variables  and  functions  by  the  game 
designer . They  have  precise  analogs  in  the  program,  analogs 
that  are  p^agogically  Inconvenient  because  of  special  coding 
to  conserve  storage.  A variable  whose  name  begins  with  a capital 
letter  may  not  correspond  to  any  program  variable;  it  is  only  a 
pedagogical  device.  If  a variable's  value  is  set  by  inputs  from 
the  game  designer — the  "game  design  data" — the  variable's  name 
is  italicized  or  underlined.  In  some  cases,  a variable's  value 
is  set  by  the  game  design  data  but  may  be  altered  later  by 
IDAHEX;  the  altered  variable  is  identified  by  the  same  name 
without  italics  or  underlining.  Examples; 

(1)  The  array  katk  is  set  by  the  game  design  data,  but 
IDAHEX  almost  immediately  redefines  it  by  multiplying 
each  element  by  tframe.  The  resulting  variable  is 
named  "katk"  to  distinguish  it. 

(2)  The  vector  of  battle  units'  locations,  huloc , is 
initially  set  by  the  design  data.  But  units' 
locations  may  change  during  the  game.  The  vector 
variable  containing  updated  unit  locations  is 
named  "buloc". 

A variable's  name  is  never  italicized  or  underlined  simply  because 
its  value  is  derived  from  game  design  data:  ultimately,  every 
variable's  value  is  determined  by  the  game  design  data  and  the 
players'  Inputs. 

The  reader  may  be  unaccustomed  to  variables'  names  contain- 
ing lower-case  letters.  The  IDAHEX  documentation  uses  program 
variables'  names  as  they  appear  in  the  MULTICS  version  of  the 
IDAHEX  computer  program.  In  MULTICS  FORTRAN  and  PL/I,  the  lower- 
case letters  constitute  the  primary  alphabet,  of  which  the  upper- 
case letters  are  an  extension.  Changing  every  lower-case  letter 
in  the  IDAHEX  source  program  to  upper-case  produces  a logically 
equivalent  program. 

Unless  the  contrary  is  affirmed,  a variable  determining  the 
number  of  elements  in  a set  may  be  0.  For  example,  the  game 
design  data  fix  the  value  of  nss(l),  the  number  of  types  of  Red 


supplies.  Such  size  parameters  let  the  game  designer  choose 
from  a spectrum  of  complexity.  At  one  end  he  can  play  several 
types  of  weapons,  several  types  of  transport,  several  types 
of  supplies,  and  several  types  of  personnel  on  each  side.  At 
the  other  end,  he  can  play  just  one  resource — an  abstract 
index  of  strength — on  each  side. 

IDAHEX  distinguishes  three  roles  for  its  user  or  users: 
the  game  designer,  who  provides  the  inputs  that  specify  the 
game  (the  game  design  data);  the  Red  player,  who  commands  the 
Red  force;  and  the  Blue  player,  who  commands  the  Blue  force. 

If  used  in  an  interactive  mode,  IDAHEX  gets  the  game  design 
data  from  one  file — ordinarily  associated  with  the  card  reader, 
a tape  data  set,  or  a disc  data  set — and  gets  the  players' 
inputs  from  one  or  two  terminals.  For  maximum  clarity,  the 
documentation  is  written  as  though  IDAHEX  is  used  interactively. 

The  term  "unit"  means  "battle  unit"  unless  the  context  in 
which  it  is  used  Indicates  otherwise.  The  phrase  "a  Red  type  i 
resource",  or  "a  Red  resource  of  type  i",  means  "a  unit-quantity 
of  Red  resources  of  Red  resource  type  1".  (Here,  "unit"  means 
"unit  of  measure",  not  "battle  unit".)  Likewise  for  Blue.  An 
element  of  a vector  or  a (two-dimensional)  matrix  may  be 
indicated  by  use  of  parenthesized  arguments  Instead  of  subscripts: 

x(l)  means  x^, 

a(  1 , j ) means  a . . . 

1 J 

The  variable  a(l,*)  is  row  1 of  the  matrix  a.  The  variable 
a(*,j)  is  column  j of  the  matrix  a.  These  may  also  be  written 
as 


^i*  • 

The  symbol  "e",  when  used  syntactically,  means  "in",  "belongs 
to",  or  "is  a member  of".  Example:  if  C is  a set,  "u  e C" 
means  "u  is  a member  of  C".  The  same  symbol  with  a line  through 
it  ("4")  means  "not  in",  "does  not  belong  to",  or  "is  not  a 
member  of".  If  y and  z are  scalar  variables,  y*z  denotes  their 
product,  and  y**z  denotes  y raised  to  the  power  z. 
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2.  THE  ELEMENTS  OF  PLAY 


This  section  explains  how  IDAHEX  structures  the  area  of 
war,  the  resources,  and  changes  in  unit  postures  and  locations. 

2. 1 THE  AREA  OF  WAR 

The  game  board  is  termed  the  "area  of  war" — the  area  in 
which  the  forces  exist.  It  is  partitioned  into  congruent, 
regular  hexagons,  as  Figure  2.1  illustrates.  The  hexagons  are 
termed  "cells".  A cell's  depth  is  defined  as  the  distance  from 
one  side  to  the  side  directly  opposite  it;  this  distance  equals 
the  distance  from  a cell's  center  to  any  adjacent  cell's  center. 
(See  Figure  2.2.)  Tne  variable  depth  is  fixed  by  the  game  design 
data.  The  cells  are  always  arranged  in  vertical  ranks  and  num- 
bered as  Figure  2.1  Illustrates.  The  number  of  cells  in  the  first 
(the  leftmost)  rank,  nrankl,  is  fixed  by  the  design  data.  (It 
is  8 in  Figure  2.1.)  The  next  rank  always  has  one  less  cell. 

The  number  of  ranks  is  Jointly  determined  by  nrankl  and  naells, 
the  number  of  cells  in  the  area  of  war.  A cell  may  be  "inactive" — 
in  effect,  excluded  from  the  area  of  war.  The  bottom  cell  in 
every  rank  (the  highest-numbered  cell  in  every  rank)  is  always 
inactive,  regardless  of  the  game  design  data.  A cell's  successors" 
are  the  cells  that  are  adjacent  to  it  and  have  larger  numbers 

than  its  own.  They  are  ordered  as  follows:  a cell's  first  suc- 

cessor is  the  cell  (if  any)  below  it,  its  second  successor  is 
the  cell  to  the  upper  right  (if  any),  and  its  third  successor  is 

the  cell  to  the  lower  right  (if  any).  By  definition,  for 

1 < n < naells  and  1 < k < Sj  [successor] (n,k)  is  the  cell  number 
of  the  k-th  successor  of  cell  n unless  cell  n is  Inactive  or  its 
k-th  successor  is  inactive  or  nonexistent,  in  which  case 
[successor ] (n,k ) = -1.  For  example,  if  all  the  cells  in  Figure 
2.1  except  the  bottom  cells  (8,  15,  23,  30,  38,  ^5,  53,  60)  are 
active , 
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[ succe 
[succe 
[succe 
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A cell's  "environment"  is  the  complex  of  physical  conditions 
in  the  cell  that  affect  combat  or  vulnerability  to  air  strikes. 
Examples:  clear,  hilly,  muddy,  urban.  The  environment  is 

assumed  to  be  uniform  throughout  the  cell.  The  environment  of 
cell  i is  coded  in  [environment] (1 ) as  a positive  integer. 

The  partitioning  of  the  area  of  war  into  hexagons  induces 
a network,  formed  by  putting  a node  in  each  cell  and  creating  an 
arc  between  each  pair  of  nodes  in  adjacent  cells.  Figure  2.3 
illustrates  it.  Coded  characterizations  of  traff icability  are 
associated  with  each  arc  (and  therefore  with  each  pair  of  adjacent 
cells).  If  cell  i and  cell  j are  adjacent,  [rtetype] (1, j ) , a 
positive  integer,  is  the  type  of  route  between  them.  One  could 
be  more  precise  and  say  that  [rtetype] (i ,j ) characterizes  the 
route  between  the  node  in  cell  i and  the  node  in  cell  j , but  such 
precision  is  spurious.  There  is  ordinarily  no  single,  geograph- 
ically identifiable  route  between  two  cells.  The  datum 
[rtetype ] (1 ,j ) is  a general  characterization  of  traf ficability 
between  the  cells,  not  a characterization  of  a particular  route 
of  march.  Indeed,  for  a task  force  in  approach  march,  several 
parallel  gravel  roads  would  probably  allow  faster  movement  than 
a single  paved  road.  By  definition,  [rtetype ] (i ,j ) ignores  barriers 
between  cell  1 and  cell  j.  Another  integer,  [bartype J(1 , j ) , 
characterizes  any  barriers  to  movement.  Barriers  include  rivers, 
ridges,  and,  in  general,  any  natural  or  man-made  obstacle  that 
affects  movement  or  attack.  If  [bartype] (i ,j ) ± 0,  it  implies 
there  are  no  barriers  between  cell  i and  cell  j.  If  positive,  it 
defines  the  type  of  barrier.  Instead  of  listing  multiple  barriers 
between  the  cells,  [bartype] (i,j ) gives  one  number  that  describes 
the  barrier  complex  as  a whole.  IDAHEX  assumes  that 

[rtetype] (i,j ) = [rtetype] (j  ,i ) 
and  [bartype](i,j ) = [bartype] (J ,1 ) 

for  each  pair  of  adjacent  cells,  i and  j.  The  format  of  the 
input  data  leaves  the  game  designer  no  choice. 

The  game  design  data  fix  the  values  of  the  variables 
[iaeic?_eny  ] , [basiajrtetypel , and  \_basio  _bartype'\  , which  are 
mapped  into  the  actual  environment  type,  actual  route  type,  and 
actual  barrier  type  by  the  game  design  variables  envmap y ftemap, 
and  barmap.  For  every  1 < i < naellsy 

[environment  ]( i ) = enymap  ( [iasicf_0ny]  (i  ) ) . 

For  every  pair  of  adjacent  cells,  1 and  j, 

[rtetype]  (i  ,j  ) = rtemap{\_basia  je‘tetype']{l  ,i)) , 

and 
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f / bapmapiLbaaioJ^artypelii  ,i)) 

Cbartype](l,j  ) = < If  lba8ia_bavtype'\{l  ,i)  > 0, 

( 0 otherwise. 

The  game  designer  may  want  to  use  very  detailed  basic  environment 
> types,  basic  route  types,  and  basic  barrier  types,  not  knowing 

how  much  detail  will  be  needed.  He  may  later  find  that  this 
detail  cannot  be  supported  by  the  data  on  movement  and  attrition, 
which  depend  upon  the  environment,  route,  and  barrier  types.  The 
maps  envmap,  rtemap,  and  barmap  can  be  set  to  compress  a large 
number  of  basic  environment  types,  basic  route  types,  and  basic 
• barrier  types  into  a manageable  number  of  actual  types  for  the 

movement  and  attrition  data.  The  maps  can  also  be  used  to  alter 
the  actual  environment  types,  route  types,  and  barrier  types 
during  the  course  of  the  game — to  reflect  changes  in  weather,  for 
example.  Initially, 

■ envmap (1)  = 1,  rtemapil)  = 1,  barmap {!)  = 1 

for  every  i.  At  the  start  of  every  cycle.  Including  the  first, 
the  game  design  data  can  modify  the  maps,  which  then  remain  fixed 
unless  and  until  the  design  data  modify  them  again. ^ (To  modify 
the  maps  is  to  change  one  or  more  elements  of  the  vectors  envmap, 
rtemap,  and  barmap.)  IDAHEX  advises  the  players  of  any  modifi- 
cations . 

Although  formally  part  of  the  area  of  war,  a cell,  1,  can 
be  effectively  excluded  by  making  its  basic  environment, 
[iasie_eny](l) , a nonpositive  integer.  The  cell  is  then 
"inactive".  No  unit  is  able  to  enter.  Only  one  word  of 
computer  storage  is  used  to  record  information  about  the  cell. 

An  attempt  by  the  design  data  to  set  [basia_rtetype'\ii  ,i)  or 
IbasiaJ^artypeliifj)  for  any  j is  ignored. 


2.2  THE  FORCES 


There  are  two  forces.  Red  and  Blue.  Each  force  consists  of 
indivisible  "battle  units",  often  called  simply  "units".  The 
game  designer  assigns  each  unit  a unique  number,  by  which  IDAHEX 
Identifies  it.  A unit's  number  must  be  a positive  integer.  The 
number  assigned  to  any  Red  unit  must  be  less  than  any  number 
assigned  to  a Blue  unit,  but  units  need  not  be  numbered  consec- 
utively. Each  unit  has  a "name" — a character  string — and  a type. 


^A  "cycle"  is  a subdivision  of  game  time.  It  is  defined  in 
Section  2.3* 
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The  complete  set  of  unit  types  for  a particular  game  might  be: 


1.  Red  motorized  rifle  division 

2.  Blue  tank  division 

3.  Red  tank  battalion 
Red  tank  division 

5.  Red  transport  unit 

6.  Blue  transport  unit 

7.  Blue  infantry  division 

Each  unit  type  is  identified  by  a positive  integer,  A unit’s 
type  is  stored  in  the  vector  butype-,  in  terms  of  the  example 
above,  if  unit  45  is  a Red  tank  division,  then  butype{^5)  = 4. 
Units  of  the  same  type  must  belong  to  the  same  side. 


2.2.1  Battle  Unit  Status 

A battle  unit's  "status"  is  described  by  its  location, 
posture,  and  objective.  Each  battle  unit  is  located  in  exactly 
one  cell.  The  unit's  location  can  not  be  fixed  more  precisely: 
the  unit  is  never  said  to  be,  for  example,  3 km  east  of  the  cell's 
center.  Its  location  is  the  cell.  Several  units  may  have  the 
same  location,  even  if  they  belong  to  different  sides. 

At  any  moment  of  the  game,  each  battle  unit  is  in  one  of  6 
"posture  classes": 

-1.  destroyed 

0.  inactive 

1.  hold 

2.  disengagement 

3.  movement 

4.  attack 

A unit  in  posture  class  2 is  trying  to  break  contact  with 
any  enemy  units  it  may  be  fighting,  as  the  first  step  in  changing 
location.  Its  "objective"  is  the  cell  toward  which  it  is  dis- 
engaging. A unit  in  posture  class  3 is  moving  from  its  location 
to  another  cell,  its  objective.  Ordinarily,  a unit  in  posture 
class  4 is  trying  to  enter  a new  location,  which  may  or  may  not 
contain  enemy  units,  but  in  some  cases  it  is  trying  to  revert 
from  posture  class  2,  3>  or  4 to  posture  class  1 without  changing 
location.  In  the  former  instance,  its  objective  is  the  cell  it 
seeks  to  enter;  in  the  latter;  its  objective  is  Just  its  present 
location . 

I 

Posture  class  1 embraces  all  remaining  activities  as  well 
as  simple  idleness.  In  particular,  a unit  in  posture  class  1 is 
I not  in  the  process  of  changing  location.  It  may  ■I'r  may  not  be 

engaged.  Its  objective  is,  by  convention,  its  location. 
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A unit  in  posture  class  -1  or  0 is  said  to  be  "inactive". 
(Inversely,  a unit  in  a positive  posture  class  is  said  to  be 
"active".)  An  inactive  unit  does  not  exist  from  the  perspectives 
of  other  units.  It  can  not  move;  it  can  not  attack,  nor  can  it 
be  attacked.  A unit  in  posture  class  -1  is  a special  kind  of 
inactive  unit:  it  was  de-activated  to  represent  its  destruction, 
usually  as  a result  of  suffering  intolerably  high  losses.  A 
unit  in  posture  class  0 is  ordinarily  a reinforcement  or  a 
package  of  replacements.  It  may  become  active  (enter  a positive 
posture  class)  later  in  the  war.  Its  location  is  the  cell  where 
it  is  expected  to  enter  the  area  of  war  if  it  becomes  active,  but 
while  it  remains  inactive,  it  has  no  effect  on  enemy  units  passing 
through  its  location. 

When  a unit,  say  unit  J,  enters  a new  posture  class,  its 
"virtual  time  of  entry",  tentry(J),  is  updated.  Normally, 
tentry(J)  is  set  to  the  exact  time  at  which  unit  J enters  the 
new  posture  class,  but  in  special  situations  it  may  be  set  to  a 
later  time.  At  the  start  of  the  game,  tentry  = tentry . The  game 
design  datum  tentryii)  is  most  simply  defined  as  the  time  at  which 
unit  j entered  the  cell  where  it  is  located  at  the  start  of  the 
game.  For  example,  if  the  game  starts  at  time  0,  if  time  is 
measured  in  days,  and  if  unit  H5  assumed  its  starting  location 
30  days  prior  to  the  starting  time,  then  tentry(i)  should  be 
-30.0 


Each  positive  posture  class  consists  of  at  least  one  posture 
and  no  more  than  10  postures.  Posture  class  -1  consists  of  Just 
one  posture,  numbered  -10.  The  postures  in  posture  class  0 are 
numbered  0 through  9,  but  IDAHEX  does  not  distinguish  among  the 
postures  in  posture  class  0.  The  postures  in  posture  classes 
1 through  ^ are  numbered  as  follows: 

10-19  hold 
20-29  disengagement 
30-39  movement 
^0-^9  attack 

Notice  that  [f loor](p/10)  is  the  posture  class  to  which  posture 
p belongs.*  There  might,  for  example,  be  two  different  movement 
postures,  representing  surface  movement  and  airborne  movement. 

There  might  be  several  different  attack  postures,  representing 
different  degrees  of  willingness  to  trade  casualties  for  space. 
Table  2.1  presents  alternative  ways  of  describing  a unit's  pos- 
ture class.  The  game  design  datum  npostil)  fixes  the  number  of 
postures  in  posture  class  1 (1  < i < 4).  There  must  be  one  pos- 
ture numbered  10,  one  numbered  20,  one  numbered  30,  and  one 
numbered  40.  These  are  the  standard  hold,  disengagement,  movement, 
and  attack  postures;  if  IDAHEX  knows  a unit's  posture  class  but 


*See  the  Glossary  for  the  definition  of  the  function  [floor]. 


Table  2.1.  EQUIVALENT  DESCRIPTIONS  OF  POSTURE  CLASS 


posture 

class 

1; 

in 

a 

hold  posture; 

holding 

posture 

class 

2; 

in 

a 

disengagement  posture; 

disengaging 

posture 

class 

3; 

in 

a 

movement  posture; 

moving 

posture 

class 

4; 

in 

an  attack  posture; 

attacking 

has  Insufficient  information  to  determine  the  posture,  it  assumes 
the  standard  posture  in  the  posture  class. 

The  postures  within  a posture  class  need  not  be  numbered 
consecutively,  but  doing  so  may  reduce  storage  requirements. 

Some  postures  within  posture  class  3 may  represent  land  or  sea 
movement  whereas  others  may  represent  air  movement.  Numbering 
the  surface  movement  postures  before  the  air  movement  postures 
(if  any)  may  reduce  storage  requirements. 


2.2.2  Battle  Unit  Resources 

The  types  of  resources  each  side  has  are  arranged  in  a list. 
For  example,  the  list  of  Red  resource  types  might  be: 

1.  tanks 

2.  small  arms  and  APCs 

3.  artillery 

4.  SAMs  and  AAA 

5.  trucks 

6.  ammunition 

7.  fuel  and  other  consumables 

8.  tank  crewmen 

9.  other  personnel 

The  Blue  list  might  be: 

1.  small  arms  and  APCs 

2.  artillery 

3.  tanks 

4.  trucks 

5.  supplies 

6 . personnel 

There  is  no  correspondence  between  Red  resource  types  and  Blue 
resource  types:  in  the  example.  Red  type  3 resources  are 
artillery  while  Blue  type  3 resources  are  tanks,  and  Red  has 
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SAMs  and  AAA  while  Blue  has  none.  The  resource  types  must  be 
listed  in  the  following  order: 

ground-to-ground  weapons 

ground-to-air  weapons 

transport 

supplies 

personnel 

These  five  resource  categories  are  combined  to  form  larger 
categories : 


materiel 


ground-to-ground  weapons 

ground-to-air  weapons 

transport 

supplies 

personnel 


weapons 


equipment 


support 


The  preceding  categories  Induce  sublists  in  each  side's  list  of 
resource  types.  In  the  example  above,  the  list  of  Red  ground- 
to-ground  weapons  is; 

1.  tanks 

2.  small  arms  and  APCs 

3.  artillery 

The  list  of  Red  weapons  is: 

1.  tanks 

2.  small  arms  and  APCs 

3.  artillery 

4.  SAMs  and  AAA 


Thus,  a Red  type  2 ground-to-ground  weapon  is  also  a Red  type  2 
weapon,  and  is  also  a Red  type  2 resource.  The  list  of  Blue 
weapons  is : 


1.  small  arms  and  APCs 

2.  artillery 

3.  tanks 

The  list  of  Red  personnel  is: 

1.  tank  crewmen 

2.  other  personnel 

The  list  of  Red  support  resources  is: 

1.  ammunition 

2.  fuel  and  other  consumables 

3.  tank  crewmen 

4.  other  personnel 
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Thus,  Red  type  2 personnel  are  also  Red  type  4 support  resources 
and  Red  type  9 resources.  Notice  that  the  category  of  Blue 
ground-to-air  weapons  is  empty,  (Hence,  the  list  of  Blue 
weapons  is  identical  to  the  list  of  Blue  ground-to-ground 
weapons. ) Any  category  except  ground-to-ground  weapons  may  be 
empty.  It  is  permissible  for  a side  to  have  only  one  type  of 
ground-to-ground  weapon,  which  would  probably  be  not  a physical 
entity  but  an  abstract  measure  of  strength. 

A unit's  type  determines  what  types  of  resources  it  can 
possess.  The  game  design  data  fix  nrstCi),  the  number  of  differ- 
ent types  of  resources  a unit  of  type  1 can  have,  and  iars(»,i), 
a list  of  the  types  of  resources  it  can  have.  Continuing  the 
example  above,  suppose: 

nratid)  = 6 

iars(l,5)  = 7 
iaz‘8(2,5)  = 6 
iar8(3»5)  = 8 
iare ,5)  = 9 
iars(5>5)  = 5 
■tars  (6, 5)  = 2 

This  says  that  a unit  of  type  5 can  have  6 types  of  resources: 

Red  type  7 resources  (fuel  and  other  consumables).  Red  type  6 
resources  (ammunition).  Red  type  8 resources.  Red  type  9 
resources.  Red  type  5 resources  (trucks),  and  Red  type  2 
resources  (small  arms  and  APCs).  The  order  in  which  the 
resource  types  appear  in  -tar8(»,5)  affects  only  the  order  in 
which  IDAHEX  lists  the  resources  of  type  5 units  internally. 

By  keeping  the  elements  of  npst  small  in  value,  the  game 
designer  can  achieve  substantial  economies  in  computer  storage 
utilization . 

The  value  of  iars {* ,5)  in  the  preceding  example  is  reasonable 
if  a type  5 unit  is  a Red  transport  unit  (as  in  the  example  at 
the  start  of  Section  2.2).  Notice  that  -’■ars(*,5)  lists  some 
resources  for  which  a transport  unit  would  have  no  use,  such 
as  tank  crewmen.  IDAHEX  allows  transfers  of  resources  between 
units,  and  therefore  resources  might  be  attached  to  a unit 
simply  to  move  them  from  one  place  to  another.  If  •tars(*,5) 
excluded  tank  crewmen,  a type  5 unit  could  not  accept  them  and 
therefore  could  never  be  used  to  take  tank  crewmen  to  a unit 
that  needed  them. 

If  1 is  the  identification  number  of  some  battle  unit,  the 
design  datum  [resources ]( 1 ,j ) is  defined  as  the  quantity  of  type 
J resources  in  the  unit  at  the  start  of  the  game.  Of  course, 
this  quantity  must  be  0 if  the  unit  is  prohibited  from  having 
type  J resources — l.e.,  if  there  is  no  1 < k < nrstihutypeiD) 
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such  that  iaps{\fiibutype{l))  = J.  At  any  time  during  the  game 
[resources](l,J ) Is  the  quantity  of  type  j resources  in  unit  1; 
it  is  set  equal  to  [resources] (i,j ) at  the  start  of  the  game. 

The  design  datum  toe(k,j)  is  defined  as  the  planned 
effective  quantity  of  type  J resources  in  a type  k battle  unit. 
It  might  be  based  on  the  Table  of  Organization  and  Equipment 
for  a type  k unit.  IDAHEX  compares  a unit's  actual  quantities 
of  resources  (given  by  [resources])  with  its  planned  effective 
quantities  in  allocating  supplies  and  replacements  to  it, 
estimating  its  strength,  and  estimating  the  size  of  its  area 
of  influence.  Of  course,  toe(k,J)  should  be  0 if  a type  k unit 
is  prohibited  from  having  type  j resources. 


2.3  TIME 

At  the  start  of  a game,  the  current  time,  t,  equals  tinit, 
which  should  be  a nonnegative  number.  The  game  ends  when 
t = tend  or  when  a player  stops  it. 

Time  is  divided  into  equal-length  intervals  called  "cycles" 
which  are  subdivided  into  equal-length  "periods",  which  are 
subdivided  into  equal-length  "frames".  Cycles,  periods,  and 
frames  may  all  be  the  same  length,  but  generally  frames  are 
shorter  than  periods.  A "break"  occurs  at  the  start  of  each 
cycle,  the  start  of  each  period,  and  the  end  of  each  frame. 

Each  break  causes  execution  of  a procedure  selected  according 
to  the  cause  of  the  break:  at  the  start  of  each  cycle,  IDAHEX 
accepts  players'  air  strike  specifications;  at  the  start  of 
each  period,  it  accepts  players'  commands;  at  the  end  of  each 
frame,  it  assesses  engagements  and  supplies  consumption. 

An  "event"  is  a break  or  a change  in  a unit's  status.  At 
t = tinit  (the  start  of  the  game),  IDAHEX  ascertains  when  the 
first  event  will  occur.  It  advances  t to  that  time  (possibly 
the  same  as  the  current  time)  and  lets  the  event  occur.  It 
then  ascertains  when  the  next  event  will  occur,  advances  t to 
that  time,  and  lets  the  event  occur.  It  continues  to  advance  t 
in  Jumps  until  t < tend  or  a player  stops  the  game  after  a break 
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MANEUVER 


A "task  force"  is  a collection  of  one  or  more  battle  units 
— "task  force  elements" — that  have  the  same  status  and  will 
continue  to  have  the  same  status  as  long  as  they  remain  in  the 
task  force.  The  elements  of  a task  force  must  all  belong  to  the 
same  side.  Each  task  force  is  identified  by  a positive  Integer; 
it  is  impossible  to  tell  from  this  number  alone  the  side  to 
which  the  task  force  belongs. 


3.1  EVENT  SEQUENCING 


A task  force's  change  of  status  is  always  caused  and 
directed  by  an  "order".  Sometimes  orders  are  generated  by 
IDAHEX;  usually  they  are  input  by  the  players.  An  order  has 
two  components:  the  desired  objective  and  the  desired  posture. 
Associated  with  an  order  may  be  a "start  time",  the  earliest  time 
at  which  the  task  force  should  begin  executing  the  order.  Exe- 
cution of  an  order  is  a process  that  may  span  time  and  may  involve 
a sequence  of  status  changes.  The  time  required  to  go  from  one 
status  to  the  next  may  be  0,  but  the  task  force  still  enters  each 
status  in  the  sequence.  Given  a task  force's  current  status  and 
its  "active  order" — the  order  it  is  executing — the  logic  of 
Figure  3-1  determines  its  next  status.  (Also  see  Figure  3*2). 


In  some  cases  the  task  force's  next  status  depends  upon 
pmapup  or  pmapdn;  specifically,  its  next  posture  is  pmapup ipp) 
or  pmapdnipp) , where  pp  is  its  present  posture.  IDAHEX  Initializes 
these  variables  as  follows: 


pmapupipp) 


pmapdnipp ) 


20; 

10 

< 

PP 

< 

19 

30; 

20 

< 

PP 

< 

29 

40; 

30 

< 

PP 

< 

39 

10; 

40 

< 

PP 

< 

49 

1-10; 

10 

< 

PP 

< 

19 

40; 

20 

< 

PP 

< 

49 

The  game  designer  can  modify  these  values,  but  the  modified 
values  must  be  such  that: 
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dpc  # ppc 


ppc  > 1 


do  # pi 


pmapup ( pp) 


I no  * do! 


> » pmapup (pp) 
) “ po 


pmapdn (pp) 


Ves 

nl  “ po 

1 No 

nl  “ pi 

pp  = present  posture  dp  = desired  posture  np  = -xt  posture^ 

= P-ren^  "location  ' ' do  = desired  objective  no  = next  objective 

po  = present  objective 


Fiaure  3.2.  STATUS  SEQUENCING  FOR  TASK  FORCE  WHOSE  PRESENT 
POSTURE  CLASS  > 0 AND  DESIRED  POSTURE  CLASS  > 0 


20 

< 

pmapup (pp) 

< 

29 

if 

10 

< 

PP 

< 

19 

30 

< 

pmapupipp) 

< 

39 

if 

20 

< 

PP 

< 

29 

40 

< 

pmapupipp ) 

< 

49 

if 

30 

< 

PP 

< 

39 

10 

< 

pmapup (pp ) 

< 

19 

if 

40 

< 

PP 

< 

49 

-10 

= 

pmapdnipp ) 

if 

10 

< 

PP 

< 

19 

40 

< 

pmapdnipp ) 

< 

49 

if 

20 

< 

PP 

< 

49 

The  positive  posture  classes  form  a cyclic  set,  and  pmapupipp) 
is  the  posture  a task  force  enters  when  it  transitions  to  the 
next  higher  posture  class:  from  posture  class  1 it  goes  to  2, 
from  2 to  3,  from  3 to  and  from  ^ to  1.  The  variable  pmapdn 
is  not  used  to  take  a task  force  from  its  present  posture  to  the 
next  lower  posture  class — that  is  generally  illegal.  Rather,  it 
tells  what  posture  a disengaging,  moving,  or  attacking  task  force 
enters  when  it  aborts  the  disengagement,  movement,  or  attack 
and  attempts  to  revert  to  a hold  posture  at  its  present  location. 
Table  3.1  contains  examples  of  status  sequencing  based  on  the 
area  of  war  depicted  in  Figure  3.3.  To  get  more  specific  examples 
let 

npost{\)  = 4,  npost{2)  = 1,  npost(3)  = 2,  npost(^)  = 3, 
and  set  pmapup  and  pmapdn  as  follows: 


PP 

pmapup (pp ) 

pmap 

10 

20 

-10 

11 

20 

-10 

12 

20 

-10 

13 

20 

-10 

20 

30 

42 

30 

40 

42 

31 

41 

42 

40 

10 

42 

41 

11 

42 

42 

13 

42 

The  preceding  assignments  are  motivated  by  the  following  inter- 
pretations of  the  postures: 

10  standard  defense 

11  halted 

12  prepared  for  transferring  resources 
to  other  units  {itrfp  = 12) 

13  hasty,  disorganized  defense 
20  disengaging 

30  tactical  march 

31  administrative  march 

40  standard  attack 

41  attack  from  administrative  march 

42  hasty,  disorganized  attack 
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Presumably,  the  ground  combat  attrition  data  make  a unit  less 
effective  on  defense  in  posture  13  than  posture  11,  and  less 
effective  in  posture  11  than  posture  10.  Likewise,  an  attacker 
should  be  less  effective  in  posture  4l  than  posture  40.  Based 
on  the  above  values  of  pmapup  and  pmapdn  and  the  area  of  war  in 
Figure  3-3,  Table  3.2  shows  the  sequence  of  statuses  Induced  by 
various  orders.  The  last  example  in  the  table  depicts  a task 
force  aborting  an  attack  and  reverting  to  a hold  posture  at  its 
present  location. 

The  preceding  configuration  can  be  simplified  (at  the  risk 
of  oversimplifying):  let  npo8t(,l)  = 2,  npo8t(2)  = npo8t(3)  = 
npo8t(^)  = 1,  and  accept  the  default  values  of  pmapup  and  pmapdn. 
Let  itrfp  = 11.  Then  a task  force  in  a hold  posture  in  cell  6 
whose  desired  posture  is  11  and  desired  objective  is  9 would  go 
through  the  following  sequence  of  statuses: 


location 

6 

6 

6 

9 

9 


posture 

20 

30 

40 

10 

11 


obj  ectlve 

9 

9 

9 

9 

9 


When  the  task  force  achieves  posture  11,  It  will  be  ready  and  able 
to  transfer  resources  to  friendly  units  located  in  cell  9.  If  the 
movement  of  supplies  and  replacements  is  to  be  played  explicitly, 
one  hold  posture  should  be  set  aside  as  a transfer  posture, 
identified  by  the  number  itrfp.  A task  force  whose 

location  = 6, 
posture  = 40, 
objective  = 9, 

and  whose 


desired  posture  = 10, 
desired  objective  = 6, 

would  go  through  the  following  sequence: 

location  posture  objective 

6 40  6 

6 10  6 

Thus,  the  task  force  aborts  an  attack  and  goes  directly  into  the 
standard  hold  posture  at  its  location;  in  contrast  to  the  last 
example  in  Table  3.2,  there  is  no  "disorganized  defense"  posture 
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Table  3.2.  EXAMPLES  OF  STATUS  SEQUENCES 


in  which  to  put  it.  Because  this  difficulty  can  arise  whenever 
the  game  designer  selects  a skeleton  configuration  of  postures, 
IDAHEX  provides  another  way  of  reducing  a task  force's  defensive 
capability  in  this  situation:  the  task  force  can  be  credited 
with  negative  defense  preparation  time.* 

In  every  example  of  task  force  movement  thus  far,  the 
objective  has  been  a cell  adjacent  to  the  task  force's  location, 
but  Figures  3.1  and  3.2  do  not  require  that.  A task  force  may 
receive  an  order  stating  a desired  objective  not  adjacent  to  its 
location.  The  task  force  will  be  able  to  execute  the  order  only 
if:  (1)  it  is  airmobile  and  (2)  the  order  causes  it  to  enter 

an  air  movement  posture.^  A unit  of  type  i is  airmobile  if  and 
only  if  mrair(.i)  >0.  A movement  posture  pp  is  an  air  movement 
posture  if  and  only  if  atrmore (pp-29 ) = .true.  Air  movement  is 
discussed  in  the  next  subsection. 


3.2  EVENT  SCHEDULING 

Associated  with  any  change  of  status  is  a delay  time.  The 
task  force  undergoing  the  change  stays  in  its  old  status  a length 
of  time  equal  to  the  delay,  and  then  enters  its  new  status.  The 
delay  is  computed  by  the  IDAHEX  function  wait,  whioh  ia  designed 
for  easy  modifiaation  or  replacement. 

Throughout  this  subsection,  u^,...,u^  are  the  unit  numbers 

of  the  task  force  elements.  The  side  to  which  they  belong  is 
s;  s = 1 if  they  are  Red,  s = 2 if  they  are  Blue.  The  task 
force's  location  is  cell  pi.  Its  posture  is  pp.  Its  posture 
class  is  ppc.  (ppc  = [floor](pp/10) . ) Its  objective  is  cell  po . 
Its  next  location  is  nl,  its  next  posture  is  np , its  next  posture 
class  is  npc  (npc  = [floor] (np/10) ) , and  its  next  objective  is  no 
The  preceding  subsection  reveals  how  the  task  force's  present 
status  (location  pi,  posture  pp,  objective  no)  and  its  active 
order  determine  its  next  status  (location  nl,  posture  np,  object! 
no).  This  subsection  shows  how  the  delay  for  the  transition 
from  the  present  status  to  the  next  status  is  determined.  Let 
d denote  that  delay. 


^Preparation  time's  effect  on  attrition  is  discussed  in  Section 
5.1.1.  The  way  an  aborted  movement  or  attack  can  lead  to 
negative  preparation  time  is  discussed  in  Section  3.3.6. 

^The  constraint  is  enforced  by  the  event  scheduling  logic, 
described  in  the  next  subsection. 


npc  = ppc,  ppc  > 0,  no  = po 


Let 

J = pp  - 10*ppc  + 1 
and  k = np  - 10*ppc  + 1. 

Thus,  posture  pp  is  the  j-th  posture  of  posture  class  ppc,  and 
posture  k is  the  k-th  posture.  The  delay  is  given  by 

d = ptran(ppc , j , k) . 

Regardless  of  the  game  design  data,  d = 0 if  J = k. 


3.2.2  From  Hold  Posture  to  Disengagement  Posture 
ppc  = 1,  npc  = 2 

In  this  case,  d = 0. 


3.2.3  From  March  Posture  to  Attack  Posture 

ppc  = 3,  npc  = 4,  no  = po,  a i rmo ve ( pp-29)  = .false. 

The  delay,  d,  in  going  from  a movement  posture  to  an  attack 
posture  with  the  same  objective  is  the  "movement  delay"-  It 
corresponds  to  the  time  the  task  force  would  need  to  move  physi- 
cally from  its  present  location  to  its  objective  if  unimpeded  by 
the  enemy.  A "march  posture"  is  any  movement  posture  other  than 
an  "air  movement  posture".  (A  task  force  in  a march  posture  might 
be  at  sea.)  If  posture  i is  a movement  posture  (30  < 1 < 39),  it 
is  an  air  movement  posture  if  and  only  if  airmove{i-29)  = .true. 
(airmove  is  a logical  variable).  Storage  is  utilized  more 
efficiently  if  the  movement  postures  are  ordered ' (numbered ) so 
that  all  the  march  postures  occur  before  air  movement  postures — 
i.e.,  if  airmoveik)  = .true,  for  some  1 < k < npost(3)  , then 
airmoveim)  = .true,  for  every  k < m < npost(3) • The  movement 
delay  for  a task  force  in  a march  posture  may  be  termed  the 
march  delay. 

If  cell  po  is  nonexistent  (po  < 1 or  po  > ncells)  or 
inactive,  then  d = +<».  ^ If  cell  po  is  not  adjacent  to  cell  pi, 
then  d = +”:  a task  force  in  a march  posture  cannot  jump  over 
cells.  Otherwise,  proceed. 


'Usually,  an  infinite  delay  results  from  a mistake  by  the  player. 
If  IDAHEX  suspects  that  is  the  case,  it  warns  the  player  of  the 
side  to  which  the  task  force  belongs,  explaining  why  the  delay 
is  infinite. 
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Initially,  suppose  that  the  task  force  consists  of  a single 
unit,  Uj^ . 

The  first  step  In  finding  d Is  ascertaining  whether  the  task 
force  has  the  supplies  it  needs  in  order  to  move;  if  naeis)  =0, 
this  step  Is  skipped.  For  every  1 < k < nssCs),  let  ssstock(k) 
be  the  quantity  of  type  k supplies  in  the  unit: 

ssstock(k)  = [resources ] (u^ ,nequip (s )+k) . 

Let 


nrs (s ) 

ssuse(k)  = S8re<7m (k , irs  ,s ) » [resources]  (u^  , irs) 

irs  = l 

for  every  1 < k < nasis).  If  ssuse(k)  > ssstock(k)  for  some 
1 < k < nss(s),  set  d = +« — the  unit  cannot  move.  Otherwise, 
proceed  to  the  next  step  to  find  d.  The  preceding  test  is 
crude  since  ssuse(k) — the  amount  of  type  k supplies  required 
for  movement — is  independent  of  [rtetype] ( pi ,po ) and 
[bartype] (pl,po) . Perhaps  the  best  strategy  is  to  make 
aareqm  underestimate  the  supplies  needed  for  a move.  One 
risks  letting  the  task  force  change  location  when  it  has 
insufficient  supplies  to  complete  the  movement,  but  if  tframe 
is  suitably  small,  the  risk  is  minor:  each  frame,  supplies 
consumption  is  assessed,  and' if  a task  force  in  a movement 
posture  exhausts  any  type  of  supplies,  its  movement  delay  is 
re-evaluated.  If  the  delay  is  found  to  be  +°°,  the  movement  is 
aborted  and  the  task  force  tries  to  revert  to  a hold  posture 
in  its  present  location. 

Given  that  the  unit  has  the  supplies  it  needs  in  order 
to  move,  the  next  step  is  to  determine  how  fast  it  can  move. 

The  unit's  basic  movement  rate  from  cell  pi  to  cell  po  is 

BMR  = mri  butype(u^)  , pp-29,  [ rtetype ] ( pi , po  ) ) . 

Thus,  its  movement  rate  depends  upon  its  type,  its  particular 
movement  posture,  and  the  type  of  route  between  the  cells.*  The 
basic  movement  rate  must  be  adjusted  to  reflect  a deficit  or 


*To  see  why  IDAHEX  allows  the  triple  dependence,  consider  an 
armored  division  making  an  administrative  movement  along 
roads  through  dense  woods.  If  it  were  making  a tactical  move- 
ment instead,  part  of  it  would  have  to  move  off-road.  If  it 
were  a straight-leg  infantry  division  instead,  it  would  have 
less  trouble  moving  off-road. 


surplus  of  transportation.  Let  TR  be  the  total  transport 
capacity  available  to  the  unit  divided  by  its  total  demand 
for  transport.  (The  latter  two  quantities  are  defined  below.) 

The  unit's  adjusted  movement  rate  is 

AMR  = fmrCiwtypeCu^) ,TR)  * BMR. 

The  degradation  (or  possibly  improvement)  factor  fmr(unit_type ,TR) 
is  computed  as  follows.  If  /mr. /(3(unlt_type)  < 0,  then  ' 

(TR  / (2  - TR);  TR  < 1 
fmr  (unit_type,  TR)  = ^ 

(l;  TR  > 1 • 

The  preceding  formula  assumes  that  th'  transport  capacity  can- 
not  be  stretched  (by  overloading  vehicles  and  operating  them 
at  reduced  speeds,  for  example);  the  transporting  resources  carry 
as  much  as  they  can,  offload  it,  and  return  to  the  point  of 
origin  for  another  load,  making  as  many  trips  as  necessary. 

If,  on  the  other  hand,  /mr . /0(unit_type ) > 0,  then 

fmr  (unit_type,  TR)  = 

paf  (TR,  /mr. /0(unit_type) , /mr. /( unit_type , *),  fmv.x). 

That  is,  fmr (unit_type , * ) is  a piecewise-af fine  (loosely  speak- 
ing, plecewise-linear ) function  whose  value  at  0 is 

/mr. /0(unit_type) , whose  value  at  fmr. xik)  is  /mr . /( unit_type , k)  « 

for  any  k,  and  whose  value  at  TR  is  found  by  interpolation. 

Thus  far,  the  unit's  movement  rate,  AMR,  has  been  determined. 

By  assumption,  the  distance  it  has  to  travel  equals  depth,  which 
equals  the  distance  between  the  centers  of  any  two  adjacent  cells. 

There  is  yet  another  factor  that  may  affect  the  movement  delay:  a ^ 

barrier  between  cell  pi  and  cell  po . The  delay  Imposed  by  a 

barrier  depends  upon  the  unit's  type,  the  unit's  posture,  and 

the  type  of  barrier.  Let  bt  = [bartype] ( pi ,po ) . A barrier 

between  cells  pi  and  po  exists  if  and  only  if  bt  > 0.  The 

unit's  march  delay  is 

depth/kV\'B,  + bdelayi  butype(u^)  , pp-29 , bt)  if  bt  > 0, 
depth/km  If  bt  = 0. 

In  summary,  the  march  delay  for  a one-unit  task  force  is 
found  as  follows: 

(1)  See  if  the  unit  has  enough  supplies  to  be  able  to  move. 

(2)  Reference  mr  to  find  the  basic  rate  at  which  the  unit 
moves  from  its  location  to  its  objective,  an  adjacent 
cell. 


I 
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(3)  Adjust  the  basic  movement  rate  according  to  the  ratio 
of  available  transport  capacity  to  the  unit's  aggregate 
demand  for  transport. 

( (t ) Divide  the  estimated  distance  to  be  traveled,  depth, 
by  the  adjusted  movement  rate;  call  the  result  dl . 

(5)  If  there  is  a barrier  between  the  unit's  location  and 
its  objective,  reference  bdelay  to  find  d2,  the  time 
needed  to  cross  the  barrier;  d2  = 0 if  no  barrier  exists. 

(6)  The  movement  delay  Is  dl  + d2. 

Now  drop  the  assumption  that  the  task  force  contains  only 
one  unit.  Recall  that  the  task  force  consists  of  the  units 
{u,  : 1 < 1 < n};  n = 1 is  allowed.  The  elements'  location  is  cell 
pi,  their  posture  is  pp,  and  their  objective  is  cell  po.  Also, 
recall  that  cell  po  must  be  adjacent  to  cell  pi  else  the  march 
delay,  d,  is  automatically  +“. 


Every  task  force  has  the  attribute  "transport  mode",  a non- 
negative  integer.  It  is  0 for  a single-element  task  force.  Let  the 
variable  named  "mode"  equal  the  transport  mode  of  the  task  force 
in  question.  The  task  force  is  "stacked"  if  and  only  if  mode  > 0. 


3. 2. 3.1  March  Delay  for  Unstacked  Task  Force 


In  this  subsection,  the  task  force  is  assumed  to  be  unstacked — 
i.e.,  mode  = 0.  As  before,  the  movement  delay  is  the  sum  of  two 
terms,  one  proportional  to  the  distance  and  inversely  proportional 
to  the  movement  rate,  and  the  other  dependent  on  the  type  of  barrier 
encountered.  By  definition,  the  task  force  moves  as  an  integral 
whole.  Therefore,  all  along  the  route,  it  moves  only  as  fast  as 
its  slowest  element.  The  elements'  supplies  and  transport  are 
pooled. 

The  first  step  is  to  determine  whether  the  task  force  has 
the  supplies  it  needs  in  order  to  move.  This  step  is  skipped 
if  nss(s)  = 0.  (Recall  that  the  task  force  belongs  to  side  s.) 

Let  ssstock(k)  be  the  amount  of  type  k supplies  in  the  task 
force  for  every  1 1 k < nss(s).  Let 


ssuse(k) 


r^(s) 


asreqm (k ,lrs ,s) 


* [resources]  (Uj^,irs) 


for  every  1 5 k < «8s(s).  If  ssuse(k)  > sstock(k)  for  some 
1 < k < nssCs),  set  d = +® — the  task  force  cannot  move.  Other- 
wise, proceed. 
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The  next  step  is  to  determine  how  fast  the  task  force  can 
move.  To  do  that,  it  is  necessary  to  determine  how  much  trans- 
port capacity  is  made  available  to  each  element.  This  is  done 
even  if  ntrpt{s)  = 0 since  resources  other  than  transport  may 
have  transport  capacity.  The  aggregate  demand  for  transport  is 

n nr^ ( s ) 

ttdemand  = ^ trnreqilrs ,s)  * [resources] (u.,irs) . 

1=1  lrs=l 

The  aggregate  transport  capacity  is 

n nrs(s) 

ttcapaclty  = ^ trnoap (Irs ,s ) * [resources] (u.,lrs) . 

1=1  lrs=l 


Let 

ittcapaclty/ttdemand;  ttdemand  > 0 
+“>;  ttdemand  = 0,  ttcapaclty  > 0 
1;  ttdemand  = ttcapaclty  = 0 

For  the  purpose  of  determining  adjusted  movement  rates,  each 
unit  receives  an  allocation  of  transport  capacity  equal  to  its 
demand  for  transport  multiplied  by  TR.  Therefore,  transport 
capacity  and  transport  demand  must  be  expressed  in  the  same 
unit  of  measure,  such  as  tons.  The  amount  of  transport  a side 
s type  i resource  requires,  tvnreq{\,s),  should  be  0 if  it  can 
move  itself.  For  example,  if  a type  i resource  is  a tank,  it 
can  not  only  transport  itself,  so  trn-peqil  ,s)  = 0;  it  can 
transport  other  resources  (a  few  people,  for  example),  so 
trncapdjs)  > 0.  Of  course,  personnel  can  move  themselves,  but 
if  side  s is  preponderantly  mechanized,  its  units'  basic  move- 
ment rates  probably  assume  the  personnel  are  mounted,  and  there- 
fore their  transport  requirements  should  be  positive. 

Because  each  task  force  element  enjoys  a ratio  of  transport 
capacity  to  transport  demand  equal  to  TR,  the  adjusted  rate  of 
movement  of  element  i (1  < i < n),  denoted  AMR(i),  is  given  by 

AMR(l)  = fmr  (fcutype(u^),  TR)  * 

mvi  butype(u^)  , pp-29,  [rtetype] (pi  ,po) ) . 

The  task  force's  adjusted  movement  rate  is 

TFAMR  = min  {AMR(i);  1 1 i 1 n)  . 

If  TFAMR  = 0,  let  dl  = +“.  Otherwise  let  dl  = depth  / TFAMR. 
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Let  bt  = [bartype] (pi ,po) . If  bt  = 0,  let  d2  = 0; 
otherwise,  let 

d2  = max  {bdelayi  butypein^) , pp-29,  bt);  1 < i < n} . 
Then  d = dl  + d2. 


3. 2. 3. 2 March  Delay  for  Stacked  Task  Force 

By  assumption,  mode  > 0.  Define  the  set  of  "carriers" 
in  the  task  force  as 

C = {u^:  trptol{butype{\i^))  - mode,  1 < i < n}, 

i.e.,  the  set  of  every  task  force  element  whose  "transport 
class"  agrees  with  the  task  force’s  transport  mode.  Define  P, 
the  set  of  "passengers",  as  the  remaining  elements  of  the  task 
force.  In  effect,  the  passengers  are  loaded  onto  the  carriers. 

The  task  force  moves  as  fast  as  the  carriers  can,  and  the 

carriers  are  able  to  draw  only  on  their  own  transport.  ! 

The  first  step  is  to  determine  whether  the  task  force  has  ! 

the  supplies  it  needs  in  order  to  move;  this  step  is  skipped  if 
MS8(s)  = 0.  For  every  1 < k < nss(s),  let  ssstock(k)  be  the  ! 

amount  of  type  k supplies  held  by  the  task  force,  not  just  the  , 

carriers.  For  every  1 < k < nss(s),  let 

nrs(s)  I 

ssuse(k)  = ^ ssreqm(k,lrs,s)  * [resources] (u, ,irs) , | 

u^eC  lrs=l  ^ 

the  amount  of  type  k supplies  that  the  carriers'  resources  need  j 

in  order  to  move.  If  ssuse(k)  > ssstock(k)  for  some  j 

1 < k < nssCs),  then  set  d = +«.  Otherwise,  proceed.  • 

The  next  step  is  to  verify  that  the  carriers  have  enough  | 

carrying  capacity  to  accommodate  the  passengers.  Only  those  j 

carrier  resources  whose  "load  class"  agrees  with  the  task  force's  j 

transport  mode  are  eligible  to  help  carry  passengers.  Let  l 


R = {1:  Zoadal{l,s)  = mode,  1 < i < nrs(s)}. 
Define  the  total  carrying  capacity  as 


CC  = y2  ^ IdaapiiyS)  * [resources] (u, ,j ) 
u^gC  JgR 
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Define  the  size  of  the  load  as 


LOAD  = 

Uj_eP 

If  LOAD  > CC,  set  d = +“  — the  task  force  cannot  move.  Other- 
wise, proceed. 


nrs (s ) 


Idsizeii^s)  * 


[resources ] (u^ ,J ) 


The  next  step  is  to  determine  whether,  after  allocating 
resources  to  carry  the  passengers,  the  carriers  have  enough 
residual  transport  capacity  to  meet  their  own  demand.  The 
fraction  of  the  carriers'  type  i resources  allocated  to  carry- 
ing passengers  is  assumed  to  be  the  same  for  each  i e R;  that 
fraction  is  LOAD/CC.  The  carriers'  total  capacity  available 
for  transporting  their  own  resources  is 

ttcapaclty  = ^ trncup  (J  ,s ) »[resources  ] (u.  ,J  ) 

u^eC  jes 

+ ^ (LOAD/CC) (j ,s ) *[resources] (u. ,J ), 

u^eC  JeR 

where  S={l:i^R,l<i<  nrs(s)}. 

Their  resources'  demand  for  transport  is 

n^(  s ) 

ttdemand  = trnreq(j,s)  * [resources] (u. ) . 

u^eC  “l 


Let 


Ittcapacity/ttdemand;  ttdemand  > 0 
+«>;  ttdemand  = 0,  ttcapaclty  > 0 
1;  ttdemand  = ttcapaclty  = 0 

The  allocation  of  transport  capacity  to  each  carrier  is 
assumed  to-  equal  its  demand  times  TR.  Therefore,  the  adjusted 
movement  rate  of  the  carrier  u^  (u^  e C)  Is  given  by 

AMR(i)  = Tmributypeiu^) , TR)  » 

mr(  butypeiu^) , pp-29,  [rtetype ] ( pi  ,po ) ) . 

The  task  force's  movement  rate  is 

TPAMR  = min  {AMR(i);  u^  e C). 
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dl  = 


depth  / TFAMR  if  TFAMR  > 0, 


otherwise . 


Let  bt  = [bartype] (pi ,po) . If  bt  = 0,  let  d2  = 0; 
otherwise,  let 

d2  = max  {bdelayi  butypeiu^) , pp-29,  bt ) ; e C}. 

Then  d = dl  + d2.  The  task  force  moves  as  fast  as  the 
slowest  carrier,  in  accordance  with  the  concept  that  the  passenger 
units  as  a group  are  borne  by  the  carrier  units  as  a group. 

3.2.4  From  Air  Movement  Posture  to  Attack  Posture 

ppc  = 3,  npc  = 4,  no  = po,  airmove {pp- 29)  = .true. 

The  air  movement  delay,  d,  is  determined  in  basically  the 
same  way  as  the  march  delay  (Section  3.2.3) • Since  the  task 
force  is  moving  above  the  surface,  its  movement  rate  is  unaffected 
by  route  types  and  barrier  types.  In  fact,  it  may  go  from  one 
cell  directly  to  a nonadjacent  cell — i.e.,  cell  po  need  not  be 
adjacent  to  cell  pi.  Nevertheless,  cell  po  must  be  in  the  area 
of  war  (1  < po  < naells)  and  must  be  active;  otherwise,  d is 
set  immediately  to  +“. 

3. 2. 4.1  Air  Movement  Delay  for  Unstacked  Task  Force 

First,  determine  whether  the  task  force  has  enough  supplies 
to  be  able  to  move.  (Skip  this  step  if  nssis)  = 0.)  For  every 
1 < k < nss(s),  let  ssstock(k)  be  the  amount  of  type  k supplies 
in  the  task  force,  and  let 

n nrs(s) 

ssuse(k)  = ^ ^ ssreqm (k, Irs , s ) * [resources] (u^, Irs) . 

i=l  irs=l 

If  ssuse(k)  > ssstock(k)  for  some  1 < k < nss(s),  then  set 
d = +<».  Otherwise,  proceed.* 


‘Suppose  both  aircraft  and  fuel 
resources.  If  side  s type  k su 
side  s type  irs  resources  are  a 
the  quantity  of  fuel  typically 
type  irs  resources.  Making  it 
the  air  movement  delay  might  be 
boundary;  then  the  movement  wou 
assessment,  which  would  prevent 
force  exhaust  essential  supplie 


are  played  explicitly  as  side  s 
pplles  Include  aviation  fuel  and 
ircraft,  ssregm(k, irs, s)  might  be 
carried  by  a unit-quantity  of 
unrealistically  small  is  risky: 

too  short  to  span  a frame 
Id  escape  supplies  consumption 
IDAHEX  from  observing  the  task 
s before  the  movement  were  complete. 


F 


Next,  let 


n nrs(s) 

ttdemand  = ^ ^ trnreqilvSyS)  * [resources] (u^, irs) , 

1=1  irs=l 

n nrs(s) 

ttcapacity  = ^ ^ trwcap ( irs , s ) * [resources] (u^, irs) . 
1=1  lrs=l 


ittcapaclty/ttdemand;  ttdemand  > 0 
+0°;  ttdemand  = 0,  ttcapacity  > 0 
1;  ttdemand  = ttcapacity  = 0 

The  task  force’s  adjusted  rate  of  movement  (through  the  air)  Is 

AMR  = min  {fmrCiwtypeCu^)  ,TR)  « mraipibutype{u^))  •,  1 < 1 < n}. 

If  AMR  = 0,  then  d = +“.  Thus,  If  a task  force  element  cannot 
move  itself  by  air,  i.e.,  if 

mrair{butype{u^))  = 0 
or  fmr(i>Mtype(u^)  ,TR)  = 0 

for  some  1 < 1 < n,  then  the  task  force  Is  unable  to  move.  If 
AMR  > 0,  then  the  movement  delay,  d,  Is  given  by 

d = dist(pl,po)  / AMR; 

dist(pl,po)  is  the  straight-line  distance  from  the  center  of 
cell  pi  to  the  center  of  cell  po . 

3. 2, 4. 2 Air  Movement  Delay  for  Stacked  Task  Force 

Define  C,  the  set  of  carriers,  and  P,  the  set  of  passengers, 
as  in  Section  3-2. 3-2. 

First,  determine  whether  the  task  force  has  enough  supplies 
to  be  able  to  move.  (Skip  this  step  if  nss(s)  = 0.)  For  every 
1 < k < nesis),  let  ssstock(k)  be  the  amount  of  type  k supplies 
held  by  the  task  force,  not  just  the  carriers,  and  let 

nrs ( s ) 

ssuse(k)  = y Bsreqm (k , Irs , s)  * [resources ] (u ., irs ) . 

Uj^eC  lrs=l  ^ 

If  ssuse(k)  > ssstock(k)  for  some  1 < k < nssis),  then  set 
d = +".  Otherwise,  proceed. 


L 


Next,  determine  whether  the  carriers  have  enough  carrying 
capacity  to  accommodate  the  passengers.  Compute  CC  and  LOAD  as 
in  Section  3. 2. 3. 2.  If  LOAD  > CC,  set  d = +«>.  Otherwise, 
proceed . 


Find  the  ratio  of  the  carriers'  residual  transport  capacity 
to  their  own  resources'  total  demand  for  transport:  compute 
ttcapacity  and  ttdemand  as  in  Section  3- 2. 3. 2,  and  define  TR  as 
there.  The  task  force's  adjusted  rate  of  movement  (through  the 
air)  is 

AMR  = min  {fmr(iutz/pe(u^)  ,TR)  * mrair{butype{u^))  ; u^  e C}. 
Then 

(dist(pl,po)  / AMR  if  AMR  > 0, 

d = 

(+<»  if  AMR  = 0. 


3.2.5  From  Disengagement  Posture  to  Movement  Posture 
ppc  = 2,  npc  = 3,  no  = po 

The  delay,  d,  in  going  from  a disengagement  posture  to  a 
movement  posture  with  the  same  objective  is  the  "disengagement 
delay".  It  is  most  simply  interpreted  as  the  time  required  to 
break  contact  with  the  enemy,  but  in  reality  a force  being 
pursued  by  the  enemy  might  never  break  contact  completely.  A 
better  interpretation  of  the  disengagement  delay  is  the  amount 
by  which  contact  with  the  enemy  increases  the  time  needed  for 
[ the  task  force  to  relocate  from  cell  pi  to  cell  po . 

1 

If  the  task  force  is  not  engaged,  set  d = 0.  Otherwise, 
proceed. 

' If  cell  po  is  not  part  of  the  area  of  war  or  is  inactive, 

or  if  cell  po  is  not  adjacent  to  cell  pi,  then  set  d = +<». 
Otherwise,  proceed. 

I 

■ If  airmove{r\p-29)  = .true.,  set  d = +»:  an  engaged  task 

I force  cannot  disengage  and  transition  directly  to  an  air 

I movement  posture.  Otherwise,  proceed. 

Define  two  situations:  (1)  there  are  friendly  units  in 
hold  postures  in  cell  pi;  (2)  there  are  no  friendly  units  in 
hold  postures  in  cell  pi.  (No  such  unit  could  belong  to  the 
task  force  since  its  posture  would  differ  from  the  task  force's 


posture . ) 


3. 2. 5.1  Disengagement  Delay  When  Enemy  Can  Not  Pursue 

In  Situation  (1)  the  friendly  units  are  assumed  to  prevent 
the  enemy  from  pursuing  the  task  force  during  Its  movement  to 
cell  po . Therefore,  the  disengagement  delay  is  Independent  of 
the  movement: 

d = max  {diseng  {.butype{\x^  ,1) 1 < i < n}. 

The  maximization  is  appropriate  because  the  task  force  can  not 
have  disengaged  until  every  element  has. 


3. 2. 5. 2 Disengagement  Delay  When  Enemy  Can  Pursue 

In  Situation  (2)  the  enemy  units  with  which  the  task  force 
is  engaged  may  be  able  to  pursue  it  during  its  movement  to 
the  adjacent  cell  po . The  disengagement  delay  therefore  is  the 
sum  of  two  terms — one  equal  to  the  basic  delay,  dl,  given  by 

dl  = max  {diseng  {butypeiu.^)  ,1)  •,  1 < i < n}  , 

and  the  other  term,  d2,  related  to  the  anticipated  movement 
delay. 

Finding  d2  parallels  Section  3.2.3.  Initially,  assume  that 
the  task  force  is  not  stacked. 

Defining  the  symbols  as  in  Section  3.2.3.1j  find  ssstock(k) 
and  ssuse(k)  for  every  1 < k < nseCs).  If  ssuse(k)  > ssstock(k)  i 

for  some  1 < k < nss{s) , set  d2  = +°°.  Otherwise,  proceed. 

Find  TR  as  in  Section  3. 2. 3.1.  Posture  np  is  a movement 
posture;  for  the  purpose  of  determining  d2,  it  is  assumed  to  be 
the  posture  in  which  the  task  force  will  move  to  cell  po . Define 
the  adjusted  movement  rate  of  task  force  element  i as  i 

AMRCi)  = fmr  (butypeiu^) , TR)  « 

mr ( butypelu^) , np-29,  [rtetype] (pi ,po) ) . 

(Cell  po  is  adjacent  to  cell  pi,  or  this  point  could  not  be 
reached.)  If  AMR(i)  = 0 for  any  i , set  d2  = +«>.  Otherwise, 
proceed.  Let 

wl  = max  {disengi  butype  {u^)  ,2)  * (ciept?2/AMR(i) );  1 < 1 < n}. 

Let  bt  = [bartype] (pi ,po ) . If  bt  = 0,  let  w2  = 0;  otherwise, 
let 
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w2  = max  {disengibutypeiu^) ,2)  * bdelay (butype (u^) ,np-29 ,ht) ; 

1 < i < n} . 

Let  d2  = wl  + w2. 

The  disengagement  delay  Is  computed  as  d = dl  + d2.  The 
computation  of  wl  and  w2  is  consistent  with  the  assumption  that 
the  task  force  moves  as  an  integral  whole  throughout  its  Journey; 
if  w2  were  smaller,  one  or  more  units  must  lag  behind  the  rest 
at  a barrier;  if  wl  were  smaller,  one  or  more  units  must  lag 
behind  along  the  route.  The  factor  diseng{i,2)  allows  for 
differences  in  the  abilities  of  different  types  of  units  to 
disengage . 

Now  assume  that  the  task  force  is  stacked.  Define  C,  the 
set  of  carriers,  as  in  Section  3. 2. 3. 2.  The  basic  delay  is  the 
same  as  before: 


dl  = max  {disengibutypeiu^)  ,1)  •,  1 < i < n}. 

Added  to  it  is  a delay,  d2,  related  to  the  anticipated  time  needed 
for  movement  to  cell  po;  d2  depends  only  on  the  carriers'  agility, 
not  the  passengers'. 

Determine  LOAD  and  CC  as  in  Section  3 *2.3 -2.  If  LOAD  > CC 
set  d2  = +“.  Otherwise,  proceed. 

Find  TR  as  in  Section  3. 2. 3. 2.  Define  the  adjusted  move- 
ment rate  of  task  force  element  i as 

AMR(i)  = fmr  {butype{u^) , TR ) * 

mr(  butypeiu^),  np-29,  [rtetype  ] ( pi  ,po  ) ) . 

If  AMR(i)  = 0 for  any  i such  that  u^  e C,  set  d2  = +<».  Other- 
wise, proceed.  Let 

wl  = max  {diseng(butype{u^)  ,2)  « {depth/ A'M'Ri  i)  ) u^,  e C}. 

Let  bt  = [bartype ] ( pi ,po ) . If  bt  = 0,  let  w2  = 0.  Otherwise 
let 

w2  = max  {diseng{butype{n^) ,2)  * 

bdelay {butype (u ^) , np-29,  bt);  u^  e C}. 

Let  d2  = wl  + w2. 

The  disengagement  delay  is  computed  as  d = dl  + d2. 
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3.2.6  From  Attack  Posture  to  Hold  Posture  at  New  Location 
ppc  = 4,  npc  = 1,  no  f pi 

The  "attack  delay"  is  0 if  cell  po  contains  no  enemy  units 
in  hold  postures.  Otherwise,  the  delay  is  indefinite:  it 
depends  upon  the  course  of  combat. 


3.2.7  To  Hold  Posture  at  Present  Location 
npc  =14  ppc.  no  = pi 

If  pp  < 0,  set  d = +“.  (A  destroyed  unit  cannot  come  back 
to  life.)  Otherwise,  proceed. 

At  this  point,  exactly  three  cases  are  possible:  (1) 

0 < PP  £ 9;  (2)  pp  > 20,  po  4 Plj  and  no  = pi;  (3)  ^0  < pp  < 49 
and  po  = pi.  (See  Section  S-l.  especially  Figure  3*1-)  Case  (1) 
occurs  when  units  in  posture  class  0 are  activated.  Case  (2) 
occurs  when  the  task  force  is  in  a disengagement,  movement,  or 
attack  posture  and  seeks  to  revert  to  a hold  posture  in  cell  pi; 
its  next  posture  is  an  attack  posture  and  its  next  objective  is 
cell  pi.  And  then  Case  (3)  applies.  In  every  case,  d = 0. 


3.2.8  Transition  to  or  within  Nonpositive  Posture  Class 
np  < 10 

The  delay  is  0.  Since  there  is  normally  no  reason  for  a 
unit  to  enter  posture  class  0 from  another  posture  class,  a 
warning  is  Issued  to  the  game  designer  if  that  happens.  The 
warning  message  is  placed  in  the  game  designer's  output  file, 
file  51. 


3.3  TACTICAL  SITUATIONS 

Because  the  forces  can  maneuver  and  the  processes  of  maneu- 
ver span  time,  situations  requiring  special  logic  may  arise.  In 
many  cases  they  require  tactical  decisions,  in  contrast  to  the 
player's  operational  decisions,  and  therefore  should  be  handled 
by  IDAHEX.  In  almost  every  case  they  must  be  handled  by  IDAHEX 
or  absurd  results  might  ensue.  Handling  these  tactical  situa- 
tions with  precision  is  not  crltical--lndeed  that  would  be 
inconsistent  with  the  model's  level  of  resolution. 

Section  3- 1 shows  how  events  are  determined,  and  Section 
3.2  shows  how  they  are  scheduled.  The  events  are  arranged 
implicitly  in  a queue  in  order  of  scheduled  occurrence;  the 
event  scheduled  to  occur  next  is  at  the  front  of  the  queue.  A 
change  of  status  by  a task  force  in  the  attack  posture  class 
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comes  after  a change  of  status  by  a task  force  In  another  posture 
class  if  both  events  are  scheduled  for  the  same  time.  When  an 
event  comes  to  the  front  of  the  queue,  t is  advanced  to  the  time  a 
at  which  it  is  scheduled  to  occur,  and  the  event  is  passed  to 
the  subprogram  xeq  for  execution.  Instead  of  executing  the  event, 
xeq  may  alter  the  queue — adding  events  to  it,  or  changing  the 
times  at  which  events  are  scheduled  to  occur  and  changing  the 
order  of  events  in  the  queue. 

Some  terms  are  needed.  To  "occupy"  a cell  is  to  change 
location  of  the  cell.  A side's  "security  force"  in  a cell 
consists  of  every  friendly  unit  that  is  located  in  the  cell  and 
is  in  a hold  posture.  A unit  or  task  force  whose  posture  is 
disengagement,  movement,  or  attack,  and  whose  objective  is  cell 
J,  is  equivalently  said  to  be  in  a disengagement,  movement,  or 
attack  posture  oriented  toward  cell  J,  or  to  be  disengaging, 
moving,  or  attacking  toward  cell  J. 

The  variable  eps  = t frame  / 100. 


3.3.1  Pursuit 


Suppose  a Blue  task  force  in  cell  1 enters  a movement 
posture  oriented  toward  cell  J,  an  adjacent  cell.  Suppose  that 
later  a Red  task  force  occupies  cell  i and  subsequently  enters 
a movement  posture  oriented  toward  cell  J . If  the  Red  task 
force  is  more  mobile,  its  movement  delay  may  be  less  than  the 
Blue  task  force's  delay — so  much  less  that  its  movement  delay 
ends  before  the  Blue  task  force's.  But  because  xeq  implements 
the  following  rule,  the  Red  task  force  cannot  occupy  cell  J 
before  the  Blue  task  force. 


Let  task  force  m and  task  force  n belong  to  opposite  sides. 
Suppose  the  location,  posture  class,  and  objective  of  task  force 
m coincide  with  the  location,  posture  class,  and  objective  of 
task  force  n.  Also  suppose  that  the  next  location,  next  posture 
class,  and  next  objective  of  task  force  m coincide  with  the  next 
location,  next  posture  class,  and  next  objective  of  task  force  n 
and  the  task  forces'  next  posture  class  differs  from  their 
present  posture  class.  Let  u^,...,Uj  be  the  identification 

numbers  of  the  units  in  task  force  m,  and  let  v^,...,Vj^  be  the 

identification  numbers  of  the  units  in  task  force  n.  If 

min  {tentry(u^);  1 < 1 £ j)  > min  {tentry(v^);  1 < i < k}, 


then  task  force  m may  enter  its  next  status  no  sooner  than  eps/i< 
after  task  force  n. 
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3.3.2  Attack 

An  important  variable  in  many  tactical  situations  is 
[owner];  [owner](i)  = 1 if  cell  1 is  owned  by  Red  and  2 if  the 
cell  is  owned  by  Blue.  The  game  design  data  set  [owner],  and 
then  IDAHEX  sets  [owner]  = [owner].  Thus,  the  design  data 
declare  the  ownership  of  each  active  cell  at  the  start  of  the 
game.  This  subsection  shows,  among  other  things,  how  [owner] 
gets  changed. 

Suppose  task  force  m,  belonging  to  side  sa  (sa  = 1 or 
sa  = 2),  is  in  an  attack  posture.  Let  sd  = 3 - sa;  side  sd  is 
its  enemy.  Suppose  the  task  force's  location  is  cell  pi,  its 
objective  is  cell  po,  its  next  posture  is  np,  and  its  next 
objective  is  no;  no  = pi  is  permitted.  Assume  posture  np  is  a 
hold  posture.  Assume  the  task  force's  attack  delay  (possibly 
0)  is  complete,  the  task  force  has  reached  the  front  of  the 
queue,  and  the  subprogram  xeq  has  been  called  to  execute  the 
task  force's  transition  to  its  next  status,  a hold  posture  in 
cell  po.  The  rest  of  this  subsection  charts  the  actions  taken 
by  xeq  in  this  case.  The  verb  "return"  means  "return  from  xeq 
to  the  calling  program". 

Step  1.  If  task  force  m is  already  engaged,  go  to  Step  6. 
Search  for  side  sd  task  forces  whose  location  is  cell  po,  whose 
posture  class  is  2,  3>  or  and  whose  objective  is  cell  pi.  If 
none  exist,  go  to  Step  2.  Do  the  following  for  each  such  task 
force:  make  its  desired  objective  po;  make  its  desired  posture 

pmapwpCpost)  if  it  is  attacking, 

pmapup (pmapup (post) ) if  it  is  moving, 

pmapup(pmapup(pmapup(post)))  if  it  is  disengaging, 

where  post  is  its  posture;  schedule  its  next  change  of  status  for 
time  t,  and  place  it  ahead  of  task  force  m in  the  queue.  Return. 
This  procedure  leads  eventually  to  an  engagement  in  which  task 
force  m is  attacking  side  sd  units  holding  in  cell  po;  it  obviates 
an  entirely  separate  combat  procedure  for  meeting  engagements. 

Step  2.  If  an  engagement  already  exists  at  cell  po,  go  to 
Step  T!  If  [owner](po)  = sa,  go  to  Step  3.  Search  for  enemy 
task  forces  in  movement  or  attack  postures  oriented  toward  cell 
po  whose  next  change  of  status  is  scheduled  to  occur  no  later 
than  t + eps.  If  none  exist,  go  to  Step  3.  Reschedule  the  next 
change  of  status  of  each  of  these  task  forces  to  time  t and  place 
it  ahead  of  task  force  m in  the  queue.  Return.  This  step 
resolves  virtual  ties  in  times  at  which  hostile  units  arrive  at 
a cell  in  favor  of  the  cell's  current  owner. 


T 
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Step  3-  Search  for  active  side  sd  units  located  In  cell 
po.  If  none  exist,  let  task  force  m change  status  (let  it 
occupy  cell  po),  let  [owner](po)  = sa,  and  return.  If  cell  po 
contains  a side  sd  unit  in  a hold  posture  other  than  posture 
itrfp,  go  to  Step  4.  Let  S be  the  set  of  every  side  sd  unit 
whose  location  is  po  and  whose  posture  is  itrfp.  Two  cases  are 
possible.  Case  1:  S is  nonempty.  In  this  case,  constitute 
every  member  of  S that  does  not  belong  to  a task  force  as  a task 
force,  give  it  the  order  "desired  objective  = po,  desired  pos- 
ture = 10",  and  position  it  in  the  queue  according  to  the  time 
of  its  next  change  of  status.  Let  T be  the  set  of  every  task 
force  whose  elements  are  members  of  S.  For  each  task  force  in 
T,  if  there  is  a start  time  associated  with  the  task  force's 
active  order,  and  it  exceeds  t,  reset  it  to  t and  therefore 
reschedule  the  task  force's  next  change  of  status.  Now  for  each 
task  force  in  T,  if  the  task  force's  active  order  specifies  a 
hold  posture  in  cell  po  and  the  next  change  of  status  is  sched- 
uled to  occur  no  later  than  t + eps,  reschedule  it  to  occur  at 
t and  move  the  task  force  ahead  of  task  force  m in  the  queue. 
Return.  Case  2:  S is  empty.  In  this  case,  let  T be  the  set 
of  every  side  sd  task  force  located  in  cell  po  whose  objective 
is  owned  by  side  sa  and  whose  objective  contains  one  or  more 
active  side  sa  units.  For  each  task  force  in  T,  determine 
whether  the  task  force  could  execute  the  first  change  of  status 
implied  by  the  order  "desired  objective  = po,  desired  posture  = 
10"  no  later  than  t + eps;  if  so,  make  that  its  active  order, 
schedule  its  next  change  of  status  for  time  t,  and  place  it 
ahead  of  task  force  m in  the  queue.  If  one  or  more  task  forces 
have  received  new  orders  in  this  way,  return. 

Step  4.  If  cell  po  contains  no  side  sd  security  force,  go 
to  Step  5-  If  [owner](pl)  = sd,  change  the  active  order  of  task 
force  m to  "desired  objective  = pi,  desired  posture  = -10", 
schedule  its  next  change  of  status  for  time  t (keep  task  force 
m at  the  front  of  the  queue),  and  return.  (The  units  in  task 
force  m are  destroyed  because  they  are  attacking  at  the  same 
time  the  enemy  owns  their  base.  It  is  inappropriate  to  let  their 
location  be  cell  pi,  and  they  have  not  been  able  to  occupy  cell 
po;  therefore  they  must  be  removed  from  the  area  of  war.  Step 
3 alters  orders  and  re-sequences  the  queue  to  avert  such  catas- 
trophes whenever  possible.)  If  there  is  no  engagement  in  prog- 
ress at  cell  po , .‘^■et  one  up  between  task  force  m and  the  side 
sd  units  in  hold  and  disengagement  postures  in  cell  po.  Other- 
wise, Join  task  force  m to  the  existing  engagement.  Reschedule 
the  next  change  of  status  of  task  force  m to  occur  at  time  t +«>. 
Return . 


* 

I 


i 

f • 


step  5-  Reaching  this  point  implies  there  is  no  side  sd 
security  force  in  cell  po,  but  one  or  more  active  units  from 
side  sd  are  located  there.  Let  S be  the  set  of  every  side  sd 
unit  whose  location  is  cell  po  and  whose  posture  is  a movement 
posture.  For  each  unit  u e S,  if  tentry(u)  > t - delta,  change 
the  unit's  posture  to  pmapupipmapupipmapupipost))) , where  post 
is  its  present  posture.  (Side  sd  units  that  started  moving 
from  cell  po  within  the  interval  delta  of  the  arrival  of  task 
force  m must  revert  to  disengagement  postures.)  Take  each  side 
sd  unit  located  in  cell  po  and  disengaging,  and  Join  it  in  an 
engagement  with  task  force  m.  Take  each  side  sd  unit  located 
in  cell  po  that  is  attacking  in  some  engagement,  constitute  it 
as  a task  force  if  not  already  an  element  of  one,  give  the  task 
force  the  active  order  "desired  objective  = po,  desired  posture 
= -10",  and  place  the  task  force  at  the  front  of  the  queue.  Let 
task  force  m enter  its  next  status.  (Let  it  occupy  cell  po. ) 
Return . 

Step  6.  This  point  is  reached  if  and  only  if  task  force  m 
is  already  engaged.  For  that  to  happen,  xeq  must  have  been 
called  once  before  to  execute  the  task  force's  transition  from 
an  attack  posture  oriented  toward  cell  po  to  a hold  posture  in 
cell  po,  and  Step  4 must  have  Joined  the  task  force  in  an  engage- 
ment. When  that  happened,  xeq  did  not  let  the  task  force  enter 
its  next  status;  in  fact,  it  rescheduled  the  change  of  status 
to  occur  after  the  end  of  the  game.  Subsequently,  the  change 
of  status  was  rescheduled  as  Section  3.3*3  explains,  and  task 
force  m again  reached  the  front  of  the  queue,  inducing  the 
current  invocation  of  xeq.  Proceed  as  follows.  Take  each  side 
sd  unit  located  in  cell  po  that  is  in  an  attack  posture  and 
engaged,  constitute  it  as  a task  force  if  it  does  not  already 
belong  to  one,  give  the  task  force  to  which  it  belongs  the  active 
order  "desired  objective  = po,  desired  posture  = -10",  and  place 
the  task  force  at  the  front  of  the  queue.  Let  task  force  m 
enter  its  next  status.  (Let  it  occupy  cell  po.)  Return. 


3.3.3  Disappearance  of  a Security  Force 

Suppose  cell  pi  is  owned  by  side  s (s  = 1 or  s = 2)  and 
contains  one  or  more  units  from  side  s in  hold  postures,  and 
suppose  one  or  more  units  from  side  3-s  are  attacking  toward 
cell  pi.  Suppose  a task  force  consisting  of  the  entire  side  s 
security  force  in  cell  pi  now  enters  posture  class  -1,  0,  or  2. 
Then  the  delay  of  every  side  s task  force  located  in  cell  pi 
and  disengaging  is  re-evaluated,  possibly  causing  rescheduling 
of  the  task  force's  next  change  of  status.  This  is  necessary 
because  a delay  computed  when  a friendly  security  force  existed 
might  no  longer  be  appropriate;  in  particular,  a disengagement 
delay  might  have  to  be  extended  now  that  the  enemy  can  pursue. 
Next,  the  active  order  of  every  side  3-s  task  force  attacking 
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toward  cell  pi  is  Inspected.  If  the  order  implies  that  the 
task  force's  next  change  of  status  is  something  other  than  Just 
a transition  to  another  attack  posture  oriented  toward  cell  pi, 
the  change  of  status  is  rescheduled  to  t and  moved  to  the  front 
of  the  queue  (giving  the  task  force  the  opportunity  to  occupy 
cell  pi).  Otherwise,  the  order  is  discarded,  so  that  the  next 
order,  if  any,  in  the  task  force's  mission  becomes  the  active 
order,  and  the  test  is  repeated. * The  process  continues  until 
either  the  test  is  passed  or  no  orders  remain  in  the  task  force's 
mission . 


3.3.4  Counterattack 

IDAHEX  structures  every  engagement  in  such  a way  that  units 
from  one  side  are  attacking  and  units  from  the  other  side  are 
defending.  A defender  is  in  a hold  posture  or  a disengagement 
posture.  It  is  possible  that  all  defenders  in  the  engagement 
are  holding,  or  all  disengaging,  or  some  holding  and  some  dis- 
engaging. The  defenders  are  all  located  in  the  same  cell,  the 
cell  under  attack,  while  the  attackers  may  be  located  in  dif- 
ferent cells.  An  attacker  is  in  an  attack  posture  unless  its 
location  is  the  same  as  the  defenders'.  In  a counterattack, 

: a task  force  consisting  of  one  or  more  defenders  disengages, 

I moves,  and  attacks  toward  the  location  of  one  or  more  of  the 

attackers.  Suppose  the  defenders'  location  is  cell  i.  Suppose 
task  force  m consists  of  one  or  more  of  the  defenders  in  hold 
i postures,  and  xeq  has  been  called  to  execute  its  transition  to 

a disengagement  posture  oriented  toward  cell  J,  the  location  of 
one  or  more  of  the  attackers.  Let  A be  the  set  of  the  attackers 
located  in  cell  J . If  task  force  m is  not  stronger  than  A, 
the  task  force's  active  order  is  changed  to  "desired  objective 
■ = 1,  desired  posture  = 10",  its  next  change  of  status  is  sched- 

' uled  for  time  t,  and  it  is  placed  at  the  front  of  the  queue. 

I If  task  force  m is  stronger  than  A,  A's  attack  is  aborted: 

I each  unit  in  A that  does  not  belong  to  a task  force  is  constl- 

' tuted  as  one;  each  task  force  contained  in  A is  given  the  active 

i order  "desired  objective  = j,  desired  posture  = 10",  its  next 

change  of  status  is  schdeuled  for  time  t,  and  it  is  placed 
ahead  of  task  force  m in  the  queue;  xeq  returns  without  execut- 
, ing  the  transition  of  task  force  m to  its  next  status.  The 

criterion  for  deciding  whether  task  force  m is  stronger  than  A 

is  as  follows.  Let  Ut,...,u  be  the  task  force's  elements, 

; 1 ’ ’ n 

I Identified  by  unit  numbers.  Let  s = 1 if  the  task  force  is  Red 

I and  s=  2 if  it  is  Blue.  The  attack  strength  of  task  force  m 

is  given  by 


1 


n nrs(s) 

fO  = S rsvalaC Irs , s ) * [resources] (u., Irs ) . 

k=l  irs=l 

The  number  rsvalaC Irs , s ) is  the  standard  value  of  a side  s 
type  Irs  resource  on  attack;  its  computation  is  explained  in 
Section  5.3-  Basically,  rsvala(irs, s)  measures  the  contrib- 
ution of  a single  type  irs  resource  belonging  to  a standard 
side  s force  attacking  a standard  enemy  force  in  a standard 
engagement.  The  defense  strength  of  task  force  m is  given  by 

n nrs(s) 

gO  = 2Z  rsvaldC irs , s ) * [resources ] (u,, irs ) . ^ 

k=l  irs=l  ' 

The  number  rsvaldC irs , s ) is  the  standard  value  of  a side  s 
type  irs  resource  on  defense.  Let  v^,...,v^  be  the  units  in 

the  set  A,  identified  by  their  numbers.  Let  s'  = 3 - s.  The 

attack  strength  of  A is  given  by  ( 

r 

fl  = 2Z  rsvalaCirSjS')  * [resources] Cv,, irs ) . ^ 

k=l 

The  defense  strength  of  A is  given  by  ' 

r 

gl  = y]  rsvaldCirSjS')  * [resources] Cv,, irs ) . 
k=l 

Task  force  m is  considered  stronger  than  A if  and  only  if  j 

fO  > fl 
gl  gO  ‘ 


3.3.5  Activation  of  Inactive  Task  Force  ] 

Suppose  xeq  has  been  called  to  execute  the  transition  of  a 
task  force  whose  elements  are  in  a nonpositive  posture  class  to  | 

a positive  posture  class.  If  the  task  force’s  next  location  i 

Cthe  cell  where  it  will  become  active)  is  owned  by  the  enemy,  j 

or  if  one  or  more  active  enemy  units  are  located  there,  xeq 
does  not  execute  the  change  of  status  and,  instead,  reschedules 
it  for  t = +“>  and  warns  the  player  of  the  side  to  which  the 
task  force  belongs. 


i 
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^ 3.3.6  Virtual  Time  of  Posture  Class  Entry 

When  a task  force  transitions  from  its  present  status  to 
its  next  status,  tentry  may  be  reset  for  each  of  its  elements. 

Let  ppc  be  the  task  force’s  present  posture  class,  po  its 
present  objective,  and  pi  is  present  location.  Let  npc  be 
. its  next  posture  class  and  no  is  next  objective.  Let  units 

^ {u^;  1 < 1 < n}  be  its  elements. 

If  npc  = ppc,  tentry  is  not  changed.  Henceforth,  assume 
npc  ^ ppc. 

f If  npc  = 2 or  npc  = 3,  IDAHEX  sets 

tentry (u^)  = t 

for  every  1 < 1 < n.  That  is,  the  virtual  time  at  which  the  units 
enter  the  next  posture  class  equals  the  actual  time. 

If  npc  = 1,  or  if  npc  = 4 and  no  ^ pi,  IDAHEX  sets 

tentry(Uj^)  = max  {t,  tentry(Uj^)} 

for  every  1 < 1 < n. 

In  the  remaining  case,  npc  = ^ and  no  = pi;  the  task  force 
is  aborting  a disengagement,  movement,  or  attack  and  trying  to 
revert  to  a hold  posture  in  cell  pi.  If  there  is  no  enemy  task 
force  whose  objective  is  pi,  whose  location  is  not  po,  and  whose 
posture  class  is  2,  3,  or  4,  then 

tentry(u^)  -f-  max  {t,  tentry(uj^)} 

for  every  1 < 1 < n.  Otherwise,  tentry  is  determined  as  follows. 
If  ppc  = 2,  then 

tentry(u^)  max  {t,  tentry(u^)} 

for  every  1 i i i n.  If  ppc  = 3,  then 

tentry  (Uj^)  max  {t  + ( t-tentry  ( ) ) , t} 

for  every  1 < i < n;  that  is,  the  virtual  time  of  entry  is  set 
ahead  of  the  current  time  by  the  length  of  time  the  unit  has  been 
moving.  Finally,  if  ppc  = 4,  tentry(u.)  is,  for  every  1 < i < n, 
set  equal  to  t plus  the  movement  delay^that  would  be  computed  for 
the  (entire)  task  force  were  it  moving  from  cell  po  to  cell  pi  in 
posture  30. 
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Thus,  If  a task  force  aborts  a movement  or  attack  and  an 
enemy  unit  directly  threatens  to  seize  Its  location  from  the 
flank  or  rear,  tentry  for  its  elements  is  set  ahead  in  time  to 
indicate  Just  how  far  out  of  position  it  is.  Because  of  the 
way  tentry  is  set  for  transitions  into  posture  class  1,  this 
penalty  is  retained  when  the  task  force  subsequently  reverts 
to  holding  its  present  location.  The  combat  procedure  uses 
t - tentry(J)  as  a measure  of  the  length  of  time  unit  J has  had 
to  prepare  a defense;  if  unit  j has  aborted  a movement  or  attack 
and  reverted  to  holding  its  location,  its  preparation  time  may 
be  negative. 

The  combat  procedure  may  also  reset  tentry.*  If,  during 
one  frame  of  a given  engagement,  the  FEBA  (measured  by  the 
variable  feba)  advances,  then  for  each  defending  unit,  say  unit 
i,  tentry(l)  is  reset  to  tO  + tframe,  where  tO  is  the  value  of 
tentry(i)  at  the  start  of  the  frame.  Thus,  the  defenders'  level 
of  preparation  cannot  increase  while  the  attackers  are  making 
progress . 


3.3.7 


jement  Termination 


Suppose  engaged  task  force  m goes  from  a disengagement  pos- 
ture to  a movement  posture,  or  enters  a nonpositive  posture  class 
(its  units  are  destroyed  or  de-activated ) , or  breaks  off  an 
attack  and  tries  to  revert  to  a hold  posture  in  its  own  location. 
Then  xeq  deletes  the  task  force's  elements  from  their  engagement. 
If  no  units  from  their  side  remain  in  the  engagement,  then  the 
engagement  terminates.  In  this  event,  xeq  may  re-schedule  the 
times  at  which  enemy  units  that  were  engaged  enter  new  statuses. 
Suppose  task  force  n,  an  enemy  of  task  force  m,  was  participating 
in  the  terminated  engagement.  The  time  at  which  it  is  scheduled 
to  enter  its  next  status  is  reset  to  min  {tO,  tl},  where  tO  is 
the  time  at  which  it  is  presently  scheduled  to  enter  its  next 
status,  and  tl  is  the  time  at  which  the  task  force  (which  is  now 
not  engaged)  would  enter  its  next  status  if  It  were  Just  beginning 
its  transition  to  its  next  status.  The  result  is  that  disengaging 
task  forces  can  immediately  enter  movement  postures. 


‘Understanding  this  paragraph  precisely  requires  some  knowledge 
of  Section  5 ("Combat"). 
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At  the  start  of  each  period,  the  Red  player  and  the  Blue 
player  input  commands  to  IDAHEX.  A command  is  an  instruction 
to  battle  units  or  a request  for  information.  IDAHEX  prevents 
a player  from  issuing  instructions  to  enemy  units  or  obtaining 
the  enemy  player's  instructions  to  his  units.  The  commands  are 
fully  described  in  the  Player's  Manual.  This  section  discusses 
only  the  three  most  important  commands,  which  are  all  instructions 
to  battle  units. 


4.1  MISSION  COMMAND 

Recall  from  Section  3-1  that  a task  force's  change  of 
status  is  always  caused  and  directed  by  an  order.  A mission 
is  a sequence  of  orders.  Every  task  force  has  a mission,  and 
every  mission  is  assigned  to  exactly  one  task  force  (but  two 
task  forces  may  have  identical  missions).  The  same  positive 
integer  that  identifies  the  task  force  identifies  its  mission. 

A mission's  orders  are  stored  in  a pop-up  stack,  and  are 
executed  in  sequence,  from  the  top  to  the  bottom.  The  order 
at  the  top  of  the  stack  is  termed  the  "active  order".  If  there 
is  a start  time  associated  with  it,  execution  does  not  begin 
until  the  current  time  equals  or  exceeds  the  start  time.  When 
execution  of  the  order  is  completed,  it  is  removed  from  the 
stack,  and  the  next  order,  if  any,  pops  to  the  top. 

A mission  is  created  or  modified  by  the  mission  command. 

If  the  player  is  modifying  an  existing  mission,  he  identifies 
it  by  number  and  then  lists  the  new  orders  in  the  sequence 
in  which  they  are  to  be  executed.  The  new  orders  completely 
replace  the  old  orders.  If  the  player  is  creating  a new 
mission,  he  lists  the  orders,  the  elements  of  the  task  force 
(identified  by  their  unit  numbers),  and  finally,  if  there  is 
more  than  one  element,  he  selects  the  task  force's  transport 
mode.  Creation  of  the  mission  also  creates  the  task  force. 

When  the  mission  ends,  because  it  is  accomplished  or  canceled, 
the  task  force  ceases  to  exist  as  an  organizational  entity, 
and  the  number  assigned  to  it  and  its  mission  becomes  available 
for  Identifying  a new  task  force  and  mission. 
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The  following  two  examples  are  based  on  the  area  of  war  in 
Figure  3-3  and  the  posture  configuration  assumed  by  Table  3.2, 
namely: 

npost{l)  = npost{2)  = 1,  npost(3)  = 2,  npost{^)  = 3 


pp 

pmapup(pp) 

pmapdnipp) 

10 

20 

-10 

11 

20 

-10 

12 

20 

-10 

13 

20 

-10 

20 

30 

42 

30 

40 

42 

31 

41 

42 

40 

10 

42 

41 

11 

42 

42 

13 

42 

Example  1.  Assume  units  4 and  9 are  both  in  the  same  hold 
posture  in  cell  17.  In  the  following  communications  with  IDAHEX, 
the  Red  player  constitutes  units  4 and  9 as  a task  force  and 
assigns  it  a mission.  Every  line  that  IDAHEX  writes  on  a player's 
terminal  is  preceded  by  a question  mark  to  distinguish  it. 

(IDAHEX  does  not  actually  write  the  question  mark.)  The  player's 
replies  are  enclosed  in  quotation  marks. 

? Enter  command. 

"mission" 

? Enter  orders. 

"16,  31,  0" 

"16,  11,  0" 

"12,  10,  2.65" 

II  ti 

? List  task  force. 

"4,9" 

? Enter  transport  mode. 

"0" 

Each  of  the  three  lines  after  the  prompting  phrase  "Enter 
orders."  states  an  order:  the  first  number  is  the  desired 
objective,  the  second  the  desired  posture,  and  the  third  is  the 
order's  start  time.  The  mission  implies  the  following  sequence 
of  statuses  for  the  task  force  consisting  of  units  4 and  9: 


4-2 


i 


location 


posture 


obj  ectlve 


17 

20 

16 

17 

30 

16 

17 

31 

16 

17 

41 

16 

16 

11 

16 

16 

20 

12 

16 

30 

12 

16 

40 

12 

12 

10 

12 

Example  2.  Assume  the  posture  class  of  unit  21  is  0.  In 
the  following  communications  with  IDAHEX,  the  Blue  player 
creates  a mission  for  the  task  force  consisting  of  unit  21: 

? Enter  command. 

"mission" 

? Enter  orders. 

"6,  12,  0" 

"9,  12,  0" 

ti  11 


? List  task  force. 
"21" 


The  mission  implies  the  following  sequence  of  statuses  for  unit 
21: 


f 


location 

6 

6 

6 

6 

6 

9 

9 


posture 

10 

12 

20 

30 

40 

10 

12 


obj  ective 

6 

6 

9 

9 

9 

9 

9 


The  example  illustrates  one  way  of  accomplishing  re-supply  and 
replacement:  if  new  resources  should  enter  the  area  of  war 

in  cell  i at  time  tr,  the  game  design  data  should  Incorporate 
them  into  a battle  unit  whose  initial  location  is  i and 
initial  posture  class  is  0,  and  then  when  t >.  tr  the  player 
whose  side  should  receive  the  resources  can  issue  a mission 
command  to  activate  the  unit.  An  inactive  unit  first  assumes 
posture  10  when  it  is  activated.  (See  Figure  3*1.) 


Example  3-  Assume  the  posture  class  of  unit  21  is  0.  In 
the  following  communications  with  IDAHEX,  the  Blue  player  acti- 
vates unit  21  in  cell  8 instead  of  its  present  location,  cell  6: 

? Enter  command. 

"mission" 

? Enter  orders. 

"8,  0,  0" 

"8,  10,  0" 

II II 

? List  task  force. 

"21" 


The  mission  implies  the  following  sequence  of  statuses  for  unit 
21: 


location  posture  objective 

8 0 8 

8 10  8 

Thus,  a player  can  activate  one  of  his  units  in  a cell 
different  from  its  initial  location;  to  do  so,  he  must  first 
change  its  location  while  it  remains  in  posture  class  0.  This 
capability  is  necessary  since  the  location  where  a package  of 
supplies  and  replacements  should  become  available  might  depend 
on  the  course  of  the  game:  in  the  first  place,  IDAHEX  prohibits 
activation  of  a u.iit  in  a cell  owned  by  the  enemy  or  containing 
enemy  units;  and  it  may  be  convenient  to  design  the  game  so 
that  supplies  and  replacements  originate  in  corps,  army,  or  front 
depots,  which  relocate  to  keep  up  with  the  combat  forces,  rather 
than  fixed,  theater  depots.  A player  could  use  the  capability  to 
change  Inactive  units'  locations  in  order  to  cheat,  activating 
units  wherever  (and  whenever)  he  pleased.  Therefore,  IDAHEX 
places  an  advisory  message  in  the  game  designer's  output  file, 
file  51,  whenever  an  inactive  unit  changes  location. 

In  every  example  the  mission's  last  order  declares  a hold 
posture  as  the  desired  posture.  That  is  not  essential  because 
the  player  can  always  extend  (modify)  a mission  some  time  after 
creating  it.  But  he  should  avoid  letting  a task  force  complete 
its  mission  in  a posture  class  other  than  -1,  0,  or  1:  to  save 
time  IDAHEX  occasionally  assumes  that  every  disengaging,  moving, 
or  attacking  unit  belongs  to  a task  force. 


4.2  REDISTRIBUTING  RESOURCES 


One  set  of  active  units,  called  the  "givers",  can  transfer 
resources  to  another  set  of  active  units,  called  the  "takers", 
subject  to  these  restrictions:  the  givers  and  the  takers  must 
all  belong  to  the  same  side,  the  givers  and  the  takers  must  all 
have  the  same  location,  and  the  givers  must  be  in  the  transfer 
posture,  posture  itrfp.  A taker  may  be  in  any  of  the  postures 
10  through  49,  including  posture  itrfp,  and  a unit  may  be  both 
a giver  and  a taker.  If  unit  j is  a taker,  it  can  accept  any 
quantity  of  type  Irs  resources,  even  if  toe (iwtype (J ) ,lrs ) * 0, 
provided  irs  = iarsil,  butype(i))  for  some  1 < i < nrstibutypeli)) . 


4.2.1  The  Transfer  Command 

The  transfer  command  causes  an  immediate,  instantaneous 
transfer  of  resources  from  the  givers  to  the  takers.  The  command 
includes  a list  of  the  givers,  a list  of  the  takers,  and  the 
amount  of  each  type  of  resource  to  be  transferred  from  the  set  of 
givers  to  the  set  of  takers.  As  an  essential  part  of  the  command, 
the  player  declares  the  transfer  location--the  givers*  and  takers' 
location.  If  the  player  declines  to  furnish  a list  of  givers,  the 
list  consists  by  default  of  every  friendly  unit  whose  location  is 
the  transfer  location  and  vfhose  posture  is  the  transfer  posture. 

If  he  fails  to  furnish  a list  of  takers,  the  list  consists  by 
default  of  every  active,  friendly  unit  whose  location  is  the 
transfer  location  and  whose  posture  is  not  itrfp.  If,  despite 
the  defaults,  there  are  no  givers  or  no  takers,  no  transfer  is 
made,  and  the  player  is  warned.  The  player  may  also  decline  to 
declare  the  transfer  amounts  of  one  or  more  types  of  resources. 

Let  G be  the  set  of  givers,  identified  by  their  unit  numbers, 
and  T the  set  of  takers,  identified  by  their  unit  numbers.  Let 
s = 1 if  the  units  are  Red  and  s = 2 if  they  are  Blue.  If  G = T, 
then  regardless  of  what  transfer  amounts  the  player  specifies,  all 
resources  are  pooled,  and  apportioned  among  the  units.  Assume 
G = T.  Let  1 < irs  < nrs(s).  Define 

T'  = {k  e T:  iars (j ,butype (k) ) = irs  for 

some  1 < j < nrst(butype{k))} . 

T'  is  the  set  of  takers  that  can  have  type  irs  resources. 


Let 


T"  = {k  E T':  toe  (butypeiW)  ,irs)  > 0}. 

If  T"  is  nonempty,  the  resources  of  type  irs  are  redistributed 
so  that  after  redistribution 

[resources ] (k, irs ) / toe (butype (k) , Irs) 

is  the  same  for  every  k e T"  and  [resources  1 (k, irs ) = 0 for 
every  k e T - Alternatively,  if  T"  is  empty,  the  resources 

are  redistributed  so  that  [resources ] (k, irs ) is  the  same  for  every 
k E T'  (and  0 for  every  k e T - T'). 

Henceforth,  assume  G + T.  If,  for  any  1,  the  player  does  not 
declare  the  amount  of  type  i resources  to  be  transferred,  it  is 
determined  as 

min  {demand,  supply}, 

where 

demand  = ^ max  [toe {butype (k) ^1)  - [resources ] (k ,1 ) , 0} 
kET 

and 

supply  = max  { [resources ] (k ,1 ) - toe{butype{k) ,i) , 0}. 

kEG 

That  is,  each  taker  demands  the  amount  by  which  its  stock  falls 
short  of  its  planned  effective  stock,  and  each  giver  demands  the 
amount  by  which  its  stock  exceeds  its  planned  effective  stock. 

If  the  player  does  declare  the  amount  of  type  i resources  to  be 
transferred,  it  is  reset  if  necessary  so  that  it  does  not  exceed 

[resources ] (k ,1 ) , 

kEG 

the  amount  available.  Let  amt (irs)  be  the  amount  of  type  irs 
resources  to  be  transferred. 

The  first  step  in  accomplishing  the  transfer  is  allocating 
the  resources  among  the  takers.  Let  1 < irs  < nrG(s).  Define 
1'  and  T''  as  before.  For  any  k e T,  let  q(k)  be  the  quantity 
of  type  irs  resources  to  be  transferred  to  unit  k,  which  must 
now  be  determined.  If  T'  is  empty,  q(k)  is  set  to  0 for  every 


itp  _ gg^  Qf  every  k such  that  kET  but  k ^ T''. 
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k,  and  amt(irs)  is  reset  to  0.  Hence,  assume  T'  is  nonempty. 
Case  1:  T"  is  nonempty.  Then  the  quantity  amt(irs)  is  dis- 
tributed among  the  battle  units  of  so  as  to  equalize  as  much 
as  possible  their  ratios  of  actual  stock  to  planned  effective 
stock.  To  be  precise,  q(k)  is  set  to  0 for  every  k e T - T" , 
and  q(k)  is  chosen  for  every  k e 1"  to 


minimize 


subject  to 


[ 


resources  ] (k ,irs  ) -t 
toe {butype (k ) ,lrs 


q(k)  = amt(lrs) 

keT'" 

q(k)  > 0 for  every  k. 


Alternatively,  assume  Case  2:  T"  is  empty.  Then  the  quantity 
amt(irs)  is  distributed  among  the  battle  units  of  T'  so  as  to 
equalize  their  stocks  as  much  as  possible.  To  be  precise,  q(k) 
is  set  to  0 for  every  k e T - T',  and  q(k)  is  chosen  for  every 
k e T'  to 

minimize  ([resources ] (k ,irs ) + q(k))^ 

keT'V  / 


subject  to  ^ q(k)  = amt(lrs) 
keT' 

q(k)  > 0 for  every  k. 

In  both  cases,  after  q is  determined  the  transfer  occurs: 
[resources ] (k ,irs ) is  increased  by  the  quantity  q(k)  for  each 
k e T. 


To  complete  the  transfer,  the  givers  must  be  assessed  for 
the  resources  that  have  already  been  distributed  to  the  takers. 
Let  1 < irs  < nrs(s).  For  any  k e G,  let  q(k)  be  the  quantity 
of  type  irs  resources  to  be  taken  from  unit  k,  which  must  now  be 
determined.  Define 

G'  = {k  e G:  toe {butype {k) , Irs)  = 0}. 

Let 

Q = ^ [resources ] (k , irs ) . 
keG" 


For  every  k e G' , q(k)  is  set  equal  to 

min  {amt (lrs)/Q,l}  » [resources ] (k , irs ) . 

If  Q > amt(irs),  q(k)  is  set  to  0 for  every  k e G - G'. 
Otherwise , 
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q(k)  is  chosen  for  every  k e G - C'  to  equalize  as  much  as 
possible  the  units'  ratios  of  actual  stocks  to  planned  effective 
stocks:  q(k)  is  chosen  for  every  k e G - G'  to 


minimize 


E 

keG-G- 


[resources] (k,lrs ) - q(k) 


toe  {butype (k) ,irs 


subject  to 


q(k) 

keG-G-* 


amt (irs ) 


) 


q(k)  > 0 for  every  k. 

After  q is  determined  the  transfer  occurs: 

[resources  ] (k, irs  ) ■*-  [resources  ] (k, irs  ) - q(k) 
for  every  k e G. 

4.2.2  The  Delivery  Command 

The  delivery  command  allows  the  player  to  arrange  a 
transfer  of  resources  that  will  occur  automatically,  at  the 
earliest  possible  moment.  The  command  does  this  by  creating 
a "delivery  order"  (not  to  be  confused  with  the  "orders"  in 
a mission).  A delivery  order  has  four  components:  (1)  the 
delivery  task  force;  (2)  the  delivery  destination;  (3)  the 
delivery  size;  (4)  the  intended  recipients  of  the  delivery. 

The  delivery  task  force,  identified  by  number,  is  the  set  of 
battle  units  Intended  to  transfer  resources  to  another  set  of 
units.  The  delivery  destination  is  the  cell  where  the  delivery 
will  occur.  The  delivery  size  is  a number  between  0 and  1, 
inclusive,  that  Indicates  how  much  should  be  transferred.  The 
Intended  recipients  must  all  belong  to  the  player's  side.  The 
list  of  intended  recipients  may  be  empty.  Once  created,  a 
delivery  order  continues  to  exist  until  the  player  cancels  it 
or  it  is  executed.  Two  or  more  delivery  orders  may  name  the 
same  delivery  task  force,  but  if  the  delivery  destinations  are 
the  same  as  well,  confusion  may  result. 

Suppose  task  force  m has  just  entered  posture  itvfp  in 
cell  dd.  IDAHEX  must  decide  whether  the  transfer  of  resources 
will  be  governed  by  a transfer  command  that  the  player  will 
issue  later  or  by  a delivery  order.  IDAHEX  infers  that  the 
player  intends  to  issue  a transfer  command,  and  therefore  makes 
no  delivery  of  resources  at  this  time,  if  either  of  the  follow- 
ing conditions  holds: 
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(1)  with  this  change  of  status,  the  task  force 
has  accomplished  its  mission; 


(2)  with  this  change  of  status,  the  task  force 
has  completed  execution  of  its  active  order, 
and  its  new  active  order  has  a start  time 
that  exceeds  the  current  time. 

If  neither  condition  holds,  IDAHEX  searches  for  a delivery 
order--one  whose  delivery  task  force  is  m and  delivery  destina- 
tion is  dd.  If  none  is  found,  a delivery  order  is  generated, 
with  the  delivery  task  force  = m,  delivery  cell  = dd,  delivery 
size  = 1.0,  and  intended  recipients  = the  empty  set;  a generated 
delivery  order  is  treated  as  any  other  delivery  order. 

Execution  of  the  delivery  order  is  a procedure  very  similar 
to  the  one  initiated  by  a transfer  command.  Let  G be  the  set  of 
elements  of  task  force  m,  identified  by  their  unit  numbers.  G 
is  the  set  of  "givers".  Let  lambda  be  the  delivery  size,  and 
let  R be  the  set  of  Intended  recipients,  identified  by  their 
unit  numbers.  If  R is  nonempty,  let  T be  the  set  of  every  k e R 
such  that  unit  k is  active  and  located  in  cell  dd;  if  R is  empty, 
let  T be  the  set  of  every  active,  friendly  unit  located  in  cell 
dd  whose  posture  is  not  itrfp.  T is  the  set  of  "takers".  If  T 
is  empty,  of  course,  no  transfer  occurs. 

If  G = T,  then  the  resources  are  redistributed  exactly  as 
described  for  that  case  in  Section  ^.2.1. 

Assume  G + T.  The  amount  of  type  i resources  to  be  trans- 
ferred is  determined  as 

min  {demand,  supply}, 

where 

demand  = ^ max  {toe {butype {k) ,i)  - [resources ] (k ,1 ) , 0} 
kgT 


and 


supply  = lambda  » ^ max  { [resources J (k ,1 ) 


ke  G 


- toe (butype (k) ,1) , 0). 


Since  the  delivery  size,  lambda,  may  not  exceed  1,  a giver  can 
only  give  away  resources  to  the  extent  they  exceed  its  planned 
effective  stock.  The  first  step  in  accomplishing  the  delivery 
is  allocating  the  resources  among  the  takers.  The  procedure  is 
exactly  the  same  as  described  in  the  previous  subsection.  The 
second  step  is  assessing  the  givers  for  the  resources  that  have 
been  distributed  to  the  takers.  The  procedure  is  exactly  the 
same  as  described  in  the  previous  subsection. 
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5.  COMBAT 


As  Section  3* 3*2  explains,  an  engagement  arises  when  units 
from  one  side  attempt  to  occupy  a cell  containing  enemy  units  in 
hold  or  disengagement  postures.  An  engagement  is  not  precipitated 
merely  by  a task  force's  entering  an  attack  posture  oriented 
toward  a cell  containing  enemy  units  in  hold  or  disengagement 
postures.  The  engagement  arises  when  the  task  force  attempts  to 
change  status  from  the  attack  posture  oriented  toward  the  enemy- 
owned  cell  to  a hold  posture  in  the  enemy-owned  cell. ^ The  cell 
is  termed  the  "engagement  location".  The  force  that  precipitates 
the  engagement,  by  attempting  to  occupy  an  enemy-owned  cell,  con- 
stitutes the  engagement  "attackers".  Other  friendly  units  may 
join  the  engagement  later,  possibly  attacking  from  different 
locations;  they,  too,  become  "attackers".  The  enemy  units  whose 
location  is  the  attacker's  objective  and  whose  postures  are  hold 
or  disengagement  constitute  the  engagement  "defenders".  Thus,  at 
the  outset  of  the  engagement,  one  side  is  the  attacker  and  the 
other  side  is  the  defender.  These  roles  remain  fixed  throughout 
the  engagement:  even  if  the  attackers  succeed  in  occupying  the 
engagement  location,  so  that  they  are  in  hold  postures  and  no 
longer  attack  postures,  they  are  still  the  "attackers".  An  engage- 
ment ends  when  all  its  attackers  have  left  or  all  its  defenders 
have  left.  If  an  attacker's  location  is  not  the  engagement  loca- 
tion, It  leaves  its  engagement  when  its  objective  becomes  a cell 
other  than  the  engagement  location.  If  an  attacker's  location  is 
the  engagement  location,  it  leaves  its  engagement  when  it  enters 
a posture  class  other  than  1 or  2.  A defender  leaves  its  engage- 
ment when  it  enters  a posture  class  other  than  1 or  2 . Therefore, 
an  attacker  or  defender  leaves  its  engagement  if  it  is  destroyed 
(posture  class  -1). 

Usually,  a defender  leaves  its  engagement  by  entering  a 
movement  posture. ^ While  it  is  moving,  the  enemy  cannot  engage 
it.  That  is  one  reason  for  the  disengagement  delay,  and  especially 
for  making  one  term  of  the  delay  proportional  to  the  anticipated 
movement  delay.  (See  Section  3-2. 5.2.)  Loosely  speaking,  if  the 


’Sometimes,  as  Section  3.3.2  explains,  the  attempt  by  a task 
force  in  a attack  posture  to  occupy  its  objective  causes  enemy 
units  located  there  to  divert  to  hold  postures.  After  they  have 
done  so,  it  re-attempts  occupation,  precipitating  an  engagement. 

^It  is  impossible  for  a unit  to  enter  a movement  posture  oriented 
toward  its  own  location. 
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tactical  situation  implies  that  the  unit  is  vulnerable  to  pursuit 
by  engagement  attackers,  its  disengagement  delay  (hence,  the 
Interval  during  which  it  is  engaged)  is  extended  to  account  for 
the  combat  that  its  rearguard  would  have  in  reality  with  pursuing 
enemy  units. 

Each  engagement  has  a stylized  FEBA  that  measures  the 
attackers'  progress.  In  any  given  engagement,  the  variable  feba 
expresses  the  FEBA  position  as  a fraction  of  depth.  At  the  start 
of  the  engagement,  feba  =0.  At  that  point,  all  the  attackers  are 
in  attack  postures  oriented  toward  the  engagement  location.  If  the 
attackers  are  sufficiently  strong  relative  to  the  defenders,  the 
FEBA  advances — feba  increases,  to  a maximum  of  1.  One  might 
imagine  that  when  feba  is  Increasing  the  attackers  are  beating  back 
the  defenders;  a more  general,  and  more  contemporary,  interpretation 
is  that  the  attackers  are  penetrating  the  defenders'  formation.  The 
game  design  datum  febad  is  the  criterion  for  deciding  when  the 
attackers  have  penetrated  sufficiently  to  be  allowed  to  occupy  the 
engagement  location.  As  soon  as  feba  > febad,  ownership  of  the 
engagement  location  passes  to  the  attackers'  side,  the  attackers 
are  allowed  to  enter  the  cell,  and  the  defenders  are  forced  to 
disengage  and  move  out  or  be  destroyed. 

An  engagement's  FEBA  is  Independent  of  other  engagements' 

FEBAs  and  the  general  disposition  of  forces  in  the  area  of  war. 

It  may  be  interpreted  as  a measure  of  the  attackers'  penetration 
of  the  engagement  location.  But  essentially  it  is  just  an 
abstraction  used  to  determine  how  long  the  engagement  lasts  before 
the  attackers  defeat  the  defenders. 

At  the  end  of  each  frame,  the  results  of  every  engagement 
during  the  frame  are  evaluated.  If  an  engagement  starts  during 
a frame,  the  attackers  cannot  possibly  occupy  the  engagement  location 
until  the  end  of  the  frame,  when  the  engagement's  feba  is  updated. 
Therefore,  tframe  should  be  short  enough  to  avoid  delaying  attackers 
excessively. 


5.1  THE  ATTRITION  PROCESS 

Attrition  is  essentially  a Lanchester  square  process.  The 
game  design  datum  katk{±,i,k)  is  the  quantity  of  enemy  type  j 
materiel  destroyed  in  one  unit  of  time  by  a single  side  k type  i 
ground-to-ground  weapon  belonging  to  an  attacker,  under  the 
assumption  that  the  side  k weapon  allocates  all  its  fire  to  enemy 
type  J materiel.  The  quantity  destroyed  in  one  frame  is 

katk(i,J,k)  = tframe  » /catfe(i,j,k). 

The  datum  feie/(i,J,k)  is  the  quantity  of  enemy  type  J materiel  ^ 

destroyed  in  one  unit  of  time  by  a single  side  k type  1 ground- 
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to-ground  weapon  belonging  to  a defender,  under  the  assumption 
that  the  side  k weapon  allocates  all  Its  fire  to  enemy  type  J 
materiel.  The  quantity  destroyed  In  one  frame  Is 


kdef(l,j,k)  = tframe  * kdef(±,i,k). 

Let  cell  loc  be  the  engagement  location  of  a given 
engagement.  Let  units  {atk(l);  1 < 1 < natk}  be  the  attackers 
and  units  {def(l);  1 < 1 < ndef}  the  defenders.  Let  sldeA  = 1 
If  the  attackers  are  Red  and  sldeA  = 2 If  they  are  Blue;  let 
sldeD  = 3 - SldeA.  For  each  1 < 1 < nrs(sldeA),  let 


rsatk( 1 ) 


frlnv(l,atk(k) ) 


* [resources] (atk(k) ,1) , 


the  attackers'  total  quantity  of  type  1 resources  that  can  become 
actively  Involved  In  combat  or  combat  support.  The  function  frlnv 
Is  explicated  In  Section  5.^.  Briefly,  frlnv(i,j)  Is  the  fraction 
of  type  1 resources  held  by  unit  j that  are  available  for  combat. 
If  the  unit's  type  1 resources  are  equipment,  or  that  are  avail- 
able and  needed  for  combat  support  If  its  type  1 resources  are 
support  resources.  For  each  1 < 1 < nrs( sldeD),  let 

ndef 

rsdef(l)  = 2^  frlnv( 1 ,def (k ) ) * [resources] (def( k) , 1 ) , 


I 

t 

I 

i 

I I 


the  defenders'  total  quantity  of  type  1 resources  that  can 
become  actively  Involved  in  combat  or  combat  support.  The  current 
time,  t,  must  coincide  with  the  end  of  a frame.  This  subsection's 
goal  is  to  derive  the  attrition  suffered  by  each  attacker  and  each 
defender  during  the  frame  Just  ended. 


5.1.1  Determining  the  Kill  Matrices 


Select  an  attacker-defender  pair:  for  some  1 1 1 £ natk 
and  some  1 < j < ndef,  let 

unitA  = atk(i),  unitD  = def(J). 

Of  course,  unitA  is  a positive  integer  identifying  a battle  unit. 
The  phrase  "battle  unit  unitA"  is  abbreviated  below  as  simply 
"unitA".  The  phrase  "battle  unit  unltD"  is  abbreviated  as  simply 
"unitD". 


If  one  of  unitA 's  type  1 ground-to-ground  weapons 
(1  < 1 < ngffwep(sideA) ) allocates  all  its  fire  to  unitD's  type  J 
materiel  (1  < J < nmat ( sldeD) ) , the  basic  quantity  of  enemy  type 
J materiel  it  destroys  in  the  frame  is  katk( i,j  , sldeA)  . But  a 
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weapon  normally  does  not  allocate  all  its  fire  to  a single  type  of 
enemy  materiel.  This  is  not  just  a matter  of  doctrine.  In  reality, 
there  might  be  several  different  types  of  materiel  at  which  a 
weapon  would  fire;  what  it  actually  fired  at  would  depend  upon 
what  targets  it  detected,  and  that  would  depend  upon  the  compo- 
sition and  deployment  of  the  enemy  force.  Two  variables  are 
used  to  adjust  katk( i , J , sideA ) for  the  allocation  of  fire — 

* , sideD)  and  , sideA) . The  game  design  datum 

,sideD)  is,  for  1 < J £ nmat(sideD),  the  quantity  of 
type  J materiel  in  a standard  side  sideD  combat  force.  The 
design  datum  i ,j  , sideA ) is  the  fraction  of  fire  of  a type 

i weapon  from  side  sideA  that  is  allocated  to  enemy  type  J 
materiel  if  the  enemy  materiel  belongs  to  a standard  enemy  force. 

Let  n = nmat( sideD).  The  fraction  of  fire  of  unitA's  type  i 
ground-to-ground  weapons  that  is  allocated  to  unitD's  type  J 
materiel  is 


alpha(i,J)  = 

agg'atfe(i,J  , sideA)  * ( frlnv(  J ,unltD)  * [resources](unltD,J  ) ) , 

stdtgtii , sideD ) * DEN 


where 


n 

DEN  = ^ ag’g'utfeCi  ,k,  SideA)  * (rsdef(k)  / stdtgtik , sideD))  . 
k=l 


The  divisor  DEN  is  Just  a normalizer,  to  ensure  that  the  fractions 
of  fire  allocated  to  the  various  types  of  enemy  materiel  sum  to 
1.*  Thus,  if  type  J materiel  is  overrepresented  compared  with 
the  standard  force,  more  fire  is  allocated  to  it;  if  no  type  J 
materiel  is  present,  no  fire  is  allocated  to  it. 

The  basic  quantity  of  unitD’s  type  J materiel  that  a single 
unitA  type  1 weapon  destroys  in  the  frame  is 

katk(i , J ,sideA)  » alpha(i,J). 

This  quantity  must  be  adjusted  for  the  specific  conditions  of 
the  engagement.  Each  adjustment  affects  either  the  lethality 
potential  of  unitA's  type  1 weapons  or  the  vulnerability  of 
unitD's  type  J materiel  to  all  enemy  fire.  In  the  former  case, 
the  adjustment  takes  the  form  of  a factor  applied  to  the  row 
katk(i ,*, SideA) ; in  the  latter,  it  takes  the  form  of  a factor 
apolied  to  the  column  katk(«,J , sideA) . The  adjusted  quantity 

'Because  of  this  normalization,  it  is  not  necessary  that 

( i , J , sideA ) = 1. 

J 
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of  unitD's  type  J materiel  that  a unltA  type  1 weapon  destroys 
in  the  frame  is 

K(i , j jUnitAjUnitD)  = katk(i , j ,sideA)  » alpha(i,J) 

» PA  » PD 

* EA  « ED 

* B 

* PREP 

The  sequel  defines  the  factors. 

Let  postA  be  unitA's  posture  if  unltA  is  in  an  attack 
posture;  let  postA  = ^0  if  not.  Let 

PA  = [fckar] (1 jSideA, postA) , 

which  equals  /ckarC i,sldeA,po//( postA ) ) by  definition.  The 
factor  PA  adjusts  the  lethality  of  unitA's  type  i weapons 
according  to  unitA’s  attack  posture.  Let  postD  be  unitD's 
posture.  Let 


PD  = [fckac] (j jSideD, postD) , 

which  equals  /ckaeC j ,sideD ,po// (postD) ) by  definition.  The 
factor  PD  adjusts  the  vulnerability  of  unitD's  type  j materiel 
according  to  unitD's  defense  posture. 

Let  e be  the  environment  in  the  engagement  location: 
e = [environment] (loc ) . Let 

EA  = /cfeare ( i , sideA , e ) . 

The  factor  EA  adjusts  the  lethality  of  unitA's  type  i weapons 
according  to  the  environment  in  which  the  combat  occurs.  Let 

ED  = /(?k(2c7e  ( j , sideD , e ) . 

The  factor  ED  adjusts  the  vulnerability  of  unitD's  type  j materiel. 
The  combat  is  tacitly  assumed  to  occur  in  the  engagement  location; 
hence,  the  environment  in  unitA's  location  is  irrelevant.  This 
does  not  imply  that  the  attacker  benefits  or  suffers  from  terrain 
equally  as  the  defender.  The  variables  fakare  and  fakace  provide 
factors  that  are  applied  only  to  featfeC* ,* ,sideA) , the  attacker's 
kill  matrix;  other  variables,  namely  fakdre  and  fakdoe ^ provide 
factors  that  are  applied  to  ,*  ,sideD) , the  defender's  kill 

matrix . 

Let  bt  be  the  type  of  barrier  between  unitA's  location  and 
unitD's  location:  if  cell  locA  is  unitA's  location,  bt  = 

[bartype] (locA ,loc ) . If  bt  = 0,  let  B = 1.  (If  there  is  no 
barrier,  no  adjustment  is  needed.)  If  bt  > 0 and 
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feba  < febabiht)  / depth 


let  B = i>arter(  1,  sideAjbt ) ; otherwise,  let  B = 1.  Thus,  even 
if  a barrier  exists,  its  effects  cease  when  the  attackers  have 
progressed  sufficiently. 

The  area  of  the  "area  of  influence"  of  unit  def(k) 

(1  < k < ndef)  is  zrarea(def (k) ) . ^ The  total  area  of  the  defenders’ 
combined  area  of  Influence  is  computed  as 

ndef 

defarea  = ^ zrarea(def (k) ) . 

The  engagement  variable  front  indicates  the  length  of  the  defenders’ 
line  of  contact  with  the  attackers.  Like  FEBA,  it  is  an  abstraction, 
a way  of  measuring  how  far  the  defenders  are  stretched.  If  one 
or  more  attackers  are  located  in  cell  loc,  then  front  = +«>,  if  not, 
the  value  of  front  depends  on  the  number  of  directions  from  which 
the  attack  is  coming.  If  the  attackers  are  all  located  in  the 
same  cell,  front  equals  the  length  of  any  side  of  a square  equal 
in  area  to  cell  loc  (a  hexagon) . If  the  attackers  are  located 
in  k different  cells,  where  k > 1,  then  front  equals  k times  the 
length  of  any  side  of  cell  loc.  The  depth  of  the  defense, 
defdepth,  is  given  by 

defdepth  = min  {defarea/front , depth]. 

The  defenders’  prepared  positions,  if  any,  are  assumed  to  extend 
only  to  the  depth  defdepth.  The  factor  PREP  has  two  purposes:  to 
reduce  the  vulnerability  of  a defender  holding  prepared  positions, 
and  to  Increase  the  vulnerability  of  a defender  whose  defense  is 
hasty  or  disorganized.  If  unitD  is  not  in  a hold  posture,  let 
PREP  = 1.  Alternatively,  assume  that  it  is.  The  virtual  length 
of  time  it  has  had  to  prepare  its  defense  is  t - tentry (unitD) , 
which  may  be  negative.  (See  Section  3.3.6.)  Let 

pf  = prep  (j,  side  D,  t - tentry (unitD) ) . 

(The  function  prep  is  explicated  in  Section  5.4.)  If  pf  < 1, 
unltD’s  preparation  time  is  sufficient  to  reduce  the  vulnerability 
of  its  type  J materiel  provided  it  still  holds  prepared  positions. 
Hence,  let 


*The  function  zrarea  is  explicated  in  Section  5.4. 


5-6 


} 


ipf  if  pf  < 1 and  feba  < defdepth/dept/z, 

PREP  = j 

/ 1 if  pf  < 1 and  feba  > defdepth/dept?i • 

On  the  other  hand,  pf  > 1 indicates  a hasty,  disorganized  defense, 
a condition  unlikely  to  improve  Just  because  the  attackers 
progress.  Hence,  let 

PREP  = pf  if  pf  > 1. 

That  completes  derivation  of  K( i , J ,unitA,unitD) , the  "potential" 
quantity  of  unitD's  type  J materiel  (1  < J < nmat(sldeD))  destroyed 
in  the  frame  by  a unitA  '(  ype  i ground-to-ground  weapon 
(1  < i < ngpuep ( sideA ) ) . Similarly,  the  potential  quantity  of 
unltA's  type  J materiel  (1  < j < nmat(sldeA))  destroyed  in  the 
frame  by  a unltD  type  i weapon  (1  < 1 < nggioepisldeD))  is 

K(l, j ,unitD,unltA)  = kdef (1, j , sideD)  * alpha'(i,J) 

* PD"  * PA" 

» ED"  * EA", 


The  factors'  definitions  are  analogous  to  those  given  above. 

Let  m = nmat(sideA).  The  allocation  factor 
alpha(l,J)  = 

ggffdefd  ,J  , SideD)  * ( f rinv(  J , unit  A ) * [resources]  (unit  A ,J  ) ) , 

stdtgtii , side A ) * DEN 


where 


m 

DEN  = ^ aggdefii,k,sldeD)  * (rsatk(k)  / stdtgt (k ,sldeA) ) . 
k=l 

Let  postD  be  unitD's  posture.  Let 

PD"  = [fckdr] (i , sideD, postD)  , 

which  equals  f akdr {i , sideD ,pof f {postD) ) by  definition.  Let  postA 
be  unitA 's  posture  if  unitA  Is  in  an  attack  posture;  let  postA  = 
^0  if  not . Let 


PA"  = [ fckdc ]( j , sldeA  , postA ) , 

which  equals  /rkdc ( j , sideA ,po//(postA ) ) by  definition.  Let 
e = [environment] (loc ) . Let 

ED'  = fakdreii , SideD ,e) , 

EA ' = fakdaeii ,sideh,e) . 
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That  completes  derl  atlon  of  the  two  potential  kill 
matrices  for  the  attacker-defender  pair  unltA-unitD, 

K( » , » junit A jUnitD)  and  K( « , » ,unitD,unltA ) . Potential  kill 
matrices  are  derived  for  each  attacker-defender  pair.* 

For  any  battle  unit  ibu  and  resource  type  Irs,  define 

ERS(ibu,lrs)  = freff(ibu)  « frlnv( irs , ibu ) * [resources] ( ibu, irs ) . 

It  is  the  effective  quantity  of  the  unit's  type  irs  resources  that 
can  become  actively  involved  in  combat  or  combat  support.  The 
function  freff  is  explicated  in  Section  5-4.  Briefly,  it  adjusts 
a battle  unit's  effectiveness  according  to  the  density  of  friendly 
forces  in  its  location.  Let  IGA  = nggwepisldePi) . Battle  unit 
unltD's  potential  loss  of  type  j materiel  (1  < J < nmat(sideD)) 
in  the  frame  due  to  all  enemy  ground  fire  is,  by  definition, 

ploss (unitD, J ) = 


K(1,J ,atk(k) ,unltD)  * ERS (atk(k ) ,i ) . 


Let  IGD  = nggwep (sldeD) . Battle  unit  unltA's  potential  loss  of 
type  J materiel  (1  < j i nmat(sldeA))  in  the  frame  due  to  all 
enemy  ground  fire  Is,  by  definition. 


ploss (unltA, J ) = 
ndef  IGD 


c=l 


, j ,def (k ) ,unltA)  * ERS (def (k) ,i ) . 


Associated  with  potential  losses  of  materiel  are  potential  losses 
of  personnel.  (Notice  that  no  fire  is  allocated  directly  to 
personnel.)  Let  nm  = nmat(sldeD).  Unit  unitD's  potential  loss 
of  type  p personnel  (1  < p £ npers (sldeD) ) due  to  all  enemy  ground 
fire  is,  by  definition, 

ploss (unltD, nm+p)  = 

nm  natk  IS^  / \ 

yj  ( K (1 , J ,atk (k ) ,unltD)  * ERS(atk(k) ,i ) j 

J^l  i^l  i^l'  ' 

* dpersr{p ,1 ,J ) 


*To  conserve  storage,  the  IDAHEX  computer  program  uses  none  of 
these  matrices.  Of  course,  it  gets  the  same  results. 


t 


>• 

I 


if  sldeD  = 1 and 


ploss (unltD,nm+p ) = 


,atk(k)  ,unitD)  « ERS(atk(k)  ,i 
* dpersb (p ,1 ,J ) 


if  sideD  = 2.  Let  nm  = nmat ( sideA ) . Unit  unitA's  potential  loss 
of  type  p personnel  (1  < p < npers ( sideA) ) due  to  all  enemy  ground 
fire  is 


ploss (unitA,nm+p ) = 
nm  ndef  IGD  / 

5£  £(“■'• 


def  (k)  ,unltA)  * ERS(def  ( k) , i 
* dpersrip ) 


if  sideA  = 1 and 


ploss (unitAjUm+p ) = 

nm  ndef  IGD  / \ 

^ f K(l,j ,def(k),unltA)  * ERS (def (k ) ,i )j 

* dpersbip ,i  ) 


j=l  k=l  i=l 
if  sideA  = 2. 


A unit’s  potential  losses  might  exceed  what  it  has.  To 
determine  actual  losses,  a sequence  of  adjustments  are  made. 

The  first  step  is  determining  the  values  for  the  resources  in 
the  engagement.  The  values  are  returned  by  the  subprogram  app, 
whose  arguments  include  a single  kill  matrix  for  all  the  attackers 
and  a single  kill  matrix  for  all  the  defenders.  This  subsection 
concludes  by  explaining  the  derivation  of  these  average  kill 
matrices.  The  next  subsection  explains  app. 


Let  1 < 1 < IGA  and  1 < j < IGD.  Let  I < k < natk.  The 
total  potential  destruction  of  enemy  type  J weapons  attributed 
to  all  the  type  i weapons  of  attacker  k equals 

ndef 

K(i,J,atk(k),def(Jl))  * ERS(atk(k)  ,i  ) . 

The  formula  commits  no  double-counting  because  the  array  K takes 
into  account  the  allocation  of  type  i weapons'  fire  to  the  various 
types  of  materiel  in  the  various  enemy  units.  The  total  potential 

5-9 
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destruction  of  enemy  type  J weapons  attributed  to  all  the 
attackers'  type  1 weapons  equals 

natk  ndef 

K(i,j  ,atk(k),def(Jl) ) » ERS(atk(k)  ,i  ) . 

i^i  1^1 


Therefore,  the  average  potential  destruction  of  enemy  type  J 
weapons  attributed  to  a type  i weapon  that  is  effectively, 
actively  Involved  in  combat  is 


A(1,J) 


natk  ndef 

E E 

k=l  4=1 


K(l,j,atk(k),def(£))  * ERS (atk(k ) ,i  ) 


natk 

^ ERS(atk(k) ,i) 


The  matrix  A is  an  average  kill  matrix  for  the  attackers  as  a 
whole.  The  defenders'  average  kill  matrix,  D,  is  defined 
analogously:  for  1 < 1 < IGD  and  1 < j < IGA, 


D(1,J) 


ndef  natk 


K(i,j  ,def  (k)  ,atk(il) ) * ERS(def  (k)  ,1 ) 


ndef 


ERS(def (k) ,1) 


The  matrices  A and  D are  passed  to  the  subprogram  app  for 
use  in  the  antipotential  potential  method.  In  that  context,  a 
theoretically  rigorous  approach  would  create  A and  D not  by 
averaging  (as  above)  but  by  using  artificial  weapon  types. 
Unless 


K(i,J ,atk(k' ) ,def ( 4) ) = K(i , j ,atk(k' ') ,def ( 4) ) 


and 


K( J ,1 ,def ( 4 ) ,atk(k' ) ) = K( J ,i ,def ( 4 ) ,atk(k  " ' ) ) 

for  every  1 < j < IGD  and  1 < 4 < ndef,  it  would  re-classify 
type  i weapons  belonging  to  attacker  k'  and  type  1 weapons 
belonging  to  attacker  k"  as  two  different  types  of  weapons. 
And  unless 

K(i ,j ,def (k') ,atk(4) ) = K(1 , J ,def (k ' ' ) ,atk ( 4 ) ) 

and 
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K(J,l,atk(i),def(k'))  = K ( j ,1 ,atk ( A ) ,def (k ' ' ) ) 

for  every  1 < j < IGA  and  1 < «■  < natk,  it  would  re-classlfy 
type  1 weapons  belonging  to  defender  k'  and  type  i weapons 
belonging  to  defender  k"  as  two  different  types  of  weapons. 
Corresponding  to  an  increase  in  the  number  of  different  types 
of  weapons  the  attackers  and  defenders  had  would  be  an  increase 
in  the  number  of  rows  and  columns  of  A and  D.  The  matrices  might 
grow  so  large  that  they  required  too  much  main  storage  and  led 
to  excessive  execution  times  for  app. 

5.1.2  Determining  Weapons'  Values 

The  antipotential  potential  method  finds  consistent  values 
(antipotential  potentials)  for  weapons  based  on  the  rates  at 
which  they  destroy  enemy  weapons.  It  was  discovered  indepen- 
dently by  Spudich  [6]  (also  see  [7])j  by  Dare  and  James  [3]> 
and  by  Thrall  and  Howes  [5].  Their  work  was  synthesized  by 
Anderson  [2].  The  IDAHEX  subprogram  app  determines  the  value  of 
each  type  of  weapon  in  a given  engagement.  The  present  version 
of  app  computes  these  values  from  the  kill  matrices  A and  D, 
derived  in  Section  5.1.1,  by  Holter's  version  of  the  anti- 
potential  potential  method  [4]. 

Recall  that  A(l,j)  is  the  (average)  rate  at  which  a type  i 
ground-to-ground  weapon  belonging  to  the  attackers  kills  the 
defenders'  type  J ground-to-ground  weapons,  and  D(i,J)  is  the 
(average)  rate  at  which  a type  i ground-to-ground  weapon  belong- 
ing to  the  defenders  kills  the  attackers'  type  j ground-to-ground 
weapons.  Let 

m = nggwepisldeA) , n = ngguep { sldeD) . 

The  matrix  A is  m x n,  and  D is  n x m.  Let  wa  be  the  m-vector 
whose  1-th  component  is  the  amount  of  type  i weapons  held  by  the 
attackers,  and  let  wd  be  the  n-vector  whose  j -th  component  is 
the  amount  of  type  j weapons  held  by  the  defenders.  Let  va  be 
an  m-vector  and  vd  an  n-vector.  The  component  va(l)  (1  < i < m) 
is  the  value  of  a type  i weapon  belonging  to  the  attackers,  and 
vd(j)  (1  < j £ n)  is  the  value  of  a type  j weapon  belonging  to 
the  defenders;  the  values  are  derived  below. 

Some  notation  is  needed.  Suppose  v and  w are  real  s-vectors, 
and  M is  a real  r x s matrix.  Then 


">-S 


v(i)  * w(i) , 


and  M » V is  the  r-vector  whose  i-th  component  equals 
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¥ 


» v(J ) . 


(Unless  noted  otherwise,  all  vectors  are  column  vectors.)  The 
transpose  of  M is  denoted  = M(J,1)  for  every 

1 < 1 < r and  1 5 J < s . 


The  antipotential  potential  method  defines  va  and  vd  so  that, 
for  some  scalar  alpha. 


(1)  alpha  « va(l)  = ^ A(1,J)  » vd(J ) for  every  1 < 1 < m 

J = 1 

and,  for  some  scalar  delta, 

m 

(2)  delta  * vd(l)  = ^ D(l,j)  * va(J ) for  every  1 < 1 < n. 

J = 1 


Thus,  each  weapon's  value  Is  proportional  to  the  rate  at  which 
It  destroys  enemy  value.  By  equation  (2), 

m 

vd(J ) = (1/delta)  » ^ D(J,k)  * va(k). 

k=l 

Substitute  for  vd  In  equation  (1),  to  conclude 

(3)  (alpha  « delta)  * va(l) 
m n 

= 22  A(1,J)  * D(j,k)  * va(k) 

k=l  J=1 

m 

AD(l,k)  « va(k), 

k=l 

where  AD  Is  the  matrix  product  of  A and  D.  Let 

lambda  = alpha  * delta. 

Equation  (3)  says  that  va  Is  an  eigenvector  of  the  matrix  AD  and 
lambda  Is  an  eigenvalue.  According  to  the  Probenlus  Theorem, 

If  AD  Is  nonnegative  and  Irreducible,  then  equation  (3)  has  a 
solution  In  which  lambda  > 0 and  va  > 0 , and  such  a solution  Is 
unique  up  to  multiplication  of  va  by  a positive  scalar.  Of 
course,  AD  Is  nonnegative.  The  matrix  AD  Is  "Irreducible" 

If  and  only  If  It  Is  not  "reducible".  By  definition,  AD  Is 
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reducible  if  and  only  if  re-ordering  its  rows  and  columns 
can  put  it  in  the  form 


r -L'  ° 1 

L M3  I M2  J . 

where  Ml  and  M2  are  square  matrices  and  all  the  elements  in  the 
upper  right-hand  block  are  zero.  Permuting  the  rows  and  columns 
of  AD  is  equivalent  to  permuting  the  rows  of  A and  the  columns  of 
D before  calculating  the  product  matrix.  It  follows  that  the  non 
negative  matrix  AD  is  reducible  if  and  only  if  there  are  subsets 
Al  and  A2  of  the  set  {i:  1 < i < m}  such  that:  the  number  of 
elements  in  A2  exceeds  0 and  equals  m minus  the  number  of  element 
in  Al;  and  if  A(i,J)  >' 0 for  some  i e Al  and  1 < j < n,  then 
D(J,k)  = 0 for  every  k e A2.  The  condition  holds  if,  for  example 
the  attackers'  weapons  of  a certain  type  are  invulnerable  to  the 
defenders'  fire.*  Thrall  argues  that  the  weapon  values  obtained 
by  the  antipotential  potential  method  are  meaningful  even  if  AD 
is  reducible  [5].^ 

Several  ways  of  scaling  va  and  resolving  lambda  into  the 
factors  alpha  and  delta  have  been  proposed.  Each  of  the 
following  sets  of  assumptions  uniquely  determines  va  (determines 
how  it  should  be  scaled)  and  alpha  and  delta: 


(i) 

m 

va ( i ) = 

n 

vd(i)  = 1 

(Dare  and  James) 

(il) 

1=1 

m 

delta  = ^ 

va(i). 

n 

alpha  = ^ 

vd(l) 

i=l 

i = l 

(Thrall  and  Howes) 

(iil)  delta  = <va,wa>,  alpha  = <vd,wd> 

(Spudich  in 
TATAWS  III) 


‘The  matrix  AD  is  reducible  if  D(»,J)  = 0 for  some  J,  which  is 
necessarily  true  (because  of  the  allocation  of  fire)  if  the 
attackers  have  no  type  J weapons.  IDAHEX  circumvents  this 
problem  by  working,  in  effect,  with  an  irreducible  submatrix 
of  AD. 

^His  argument  posits  that  the  antipotential  potential  method 
finds  the  weapon  values  by  an  iterative  procedure  starting 
with  all-positive  values.  Such  is  the  app  procedure. 


(iv)  alpha  = delta,  va(kw)  = 1 


(Holter) . 


In  (Iv)  kw  Is  an  Integer  In  the  Interval  [l,m].  The  requirement 
va(kw)  = 1 merely  fixes  the  scaling  of  va;  choice  of  kw  does  not 
affect  the  relative  proportions  of  the  elements  of  va  and  vd.^ 

The  present  version  of  app  Implements  (Iv). 

For  arguments  In  favor  of  scaling  assumption  (Iv)  and  against 
the  three  alternatives,  see  [^].  The  primary  consideration  In 
selecting  a scaling  assumption  Is  the  reasonableness  of  the 
resulting  force  ratio: 


FR 


<va,  wa> 
<vd,  wd> 


It  should  Indicate  which  side  is  dominant.  The  attackers  are 
said  to  dominate  if  the  force  ratio  rises  as  combat  continues. 

That  happens  if  and  only  If  the  defenders'  rate  of  value  loss  is 
bigger  in  proportion  to  their  total  value  than  the  attackers'  — 
i.e.,  the  quantity 

FR?  = A^»wa>\  / /<va,  D^*wd>\ 

\ <vd,  wd>  / / \ <va,  wa>  j 

exceeds  1.  But 

fr?  = <A*vd.  wa>  , <va.  wa> 

<D*va,  wd>  <vd , wd)> 

2 

alpha  * (<va,  wa>) 
delta  * (<vd,  wd>)^ 

The  first  of  the  two  preceding  equalities  reveals  that  the  value 
of  FR2  is  Independent  of  how  va  and  vd  are  scaled.  Under  scaling 
assumption  (iv),  the  force  ratio,  FR,  equals  the  square  root  of 
FR2  (and  therefore  exceeds  1 if  and  only  if  FR2  exceeds  1).  Under 
assumptions  (i)  and  (ii),  it  is  possible  that  FR  > 1 while  FR2  < 1, 


iSome  antipotential  potentials  may  be  0.  Of  course,  if  va(kw)  = 0, 
no  rescaling  can  make  va(kw)  = 1,  IDAHEX's  subprogram  app  chooses 
kw  to  avoid  this  contradiction  If  possible.  The  contradiction  Is 
avoidable  unless  the  only  nonnegative  solution  of  equations 
(1)  and  (2)  is  alpha  = delta  = 0,  va  = 0,  vd  = 0. 
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and  vice  versa.  Under  assumption  (111),  FR  > 1 if  and  only  if 
FR2  > 1,  but  regardless  of  the  force  ratio  the  attackers  lose 
value  at  the  same  rate  as  the  defenders: 

<va,  » wd>  = <D*va,  wd> 

= delta  » <vd,  wd> 

= <va,  wa>  * alpha 
= <A«vd , wa> 

= <vd,  A^*wa>. 

Hence,  assumption  (Iv)  appears  to  be  the  most  suitable. 

The  subprogram  app  actually  determines  the  value  of  every 
resource,  not  just  ground-to-ground  weapons.  Let  nm  = nrs(sideA) 
and  nn  = nrsCsideDj.  Let 

va(i ) ; 1 < 1 < m 

vala(l)  = 

0 j m < 1 < mm 
vd(i) ; 1 < 1 < n 

vald(i)  = 

0 ; n < 1 < nn 

Since  the  resources  other  than  ground-to-ground  weapons  cannot 
destroy  enemy  resources,  giving  them  zero  value  is  completely 
consistent  with  the  antipotential  potential  method.  Indeed,  one 
might  expand  A and  D to  include  all  resource  types,  so  A would 
have  mm  rows  and  nn  columns  and  D would  have  nn  rows  and  mm  columns. 
Of  course,  A(l,j)  would  be  0 unless  i < m,  and  D(i,J)  would  be  0 
unless  i < n.  The  vectors  vala  and  vald  defined  above  would 
satisfy  equations  (1)  and  (2)  using  the  expanded  A and  D: 

n 

alpha  * vala(l)  = A(i,j)  * vald(j) 


delta  * vald(i) 


D(i,  j ) » vald( j ) 


mm 

+ ^ D(i, j ) * vald(J ) 

J=m+1 


for  every  1 < 1 < nn. 


5.1.3  Finding  Actual  Losses 

Section  5.1.1  derives  the  potential  losses  of  materiel 
suffered  by  each  battle  unit  In  the  given  engagement.  Section 
5.1.2  derives  the  values  of  the  resources  In  the  engagement. 

Those  subsections' notation  remains  In  force.  Recall  that 
ERS(lbu,l)  Is  the  effective  quantity  of  type  1 resources  belonging 
to  battle  unit  Ibu  that  can  become  actively  Involved  In  combat 
or  combat  support.  Let 


natk 

ersatk(l)  = J]  ERS(atk(k) ,1) 
k=l 


for  every  1 < 1 < mm  (mm  = nrs ( sldeA.) ) , and 


ersdef (1 ) 


ERS(def(k) ,1) 


for  every  1 < 1 < nn  (nn  = nrs(sideD)).  The  attackers'  total 
value,  fgrd.  Is  defined  by 

mm 

fgrd  = ^ ersatk(l)  * vala(l). 

1 = 1 


The  defenders' 


total 

ggrd 


value 

nn 


ggrd,  is 
ersdef (1 ) 


defined  by 
* vald(i). 


The  engagement's  ground  force  ratio  Is 
FRGRD  = fgrd  / ggrd . 
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The  calculation 
K(»,*,atk(k;),def(i!,)) ; 
the  potential  losses, 
listed  in  Table  5.1* 
variables  by  the  game 
all  these  Influences, 
addition,  ploss  must 
combat.  Finally,  no 
of  what  it  has. 


of  the  family  of  kill  matrices 
the  average  kill  matrices,  A and  D;  and 
ploss;  considered  several  Influences, 

But  the  values  assigned  to  the  relevant 
design  data  may  not  adequately  represent 
necessitating  adjustments  to  ploss.  In 
be  scaled  according  to  the  intensity  of 
unit  should  be  assessed  losses  in  excess 


The  first  step  in  the  adjustment  process  is  determining 
a representative  posture  for  the  engagement  attackers  and  one 
for  the  defenders.  The  value  of  attacker  k is,  by  definition. 


ERS(atk(k) ,1)  » vala(l) 


Let  postA  be  that  posture  such  that  the  total  value  of  the 
attackers  in  it  is  greatest;  as  before,  an  attacker's  posture 
is  taken  to  be  ^0  if  not  an  attack  posture.  Let  postD  be  that 
posture  such  that  the  total  value  of  the  defenders  in  it  is 
greatest . 

The  next  step  compares  the  attackers'  value  loss  Implied  by 
ploss  with  the  value  loss  prescribed  by  the  engagement's  force 
ratio. ^ The  attackers'  potential  loss  of  value  is 


delval  = 


ploss (atk(k) ,i ) * vala(l). 


Let  temp  = frdval(FRGRD, postA) . (The  function  frdval  is 
explicated  in  Section  5.4.)  If  temp  < 0,  this  step  is  skipped. 

Thus,  by  appropriately  defining  the  game  design  data  used  by 
frdval,  the  game  designer  can  selectively  avert  this  step.  If 
temp  > 0,  let 

scalar  = temp  / (delval/ fgrd)  , 

and  redefine  ploss:  for  every  1 < k < natk  and  1 < irs  < nrs(sldeA) 
ploss  (atk(k) , irs ) .< — scalar  » ploss  (atk (k ),  irs  ) . 


^Thls  step  is  basically  the  same  as  one  in  IDAGAM's  attrition 
procedure  [1].  Indeed,  the  basic  structure  of  IDAHEX's 
attrition  procedure — a scaled  Lanchester  square  process — 
originated  with  IDAGAM. 
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Table  5.1.  INFLUENCES  ON  ATTRITION 


Inf 1 uence 

How  Represented 

attack  ye.  defense 

katk  vs.  kdef 

posture 

fakar,  fakaoj  fckdr^  fakda 

environment 

fokare,  fakaae,  fokdre,  fokdoe 

barriers 

hariep 

defensive  preparation 

prep 

That  Isj  the  attackers'  potential  losses  are  scaled  so  that  the 
attackers'  total  potential  loss  of  value  agrees  with  what  is 
predicted  from  the  force  ratio. 

Next,  the  same  operation  occurs  for  the  defenders.  Let 

ndef  nn 

delval  = ^ ^ ploss (def (k) ,i ) * vald(i). 

^1  i^l 

Let  temp  = frdval(FRGRD,postD) . If  temp  < 0,  this  step  is  skipped. 
Otherwise,  let 

scalar  = temp  / (delval/ggrd ) , 

and  redefine  ploss:  for  every  1 < k < ndef  and  1 < irs  < nrs(sldeD), 

ploss  (def  (k)  ,irs  )-i — scalar  * ploss  (def  (k) , irs  ) . 

The  final  step  is  scaling  ploss  according  to  the  intensity 
of  combat,  which  depends  upon  the  tactical  overlap  of  the  attack- 
ing force  and  the  defending  force.  The  tactical  overlap  is 
defined  as  the  depth  of  the  attackers'  penetration  of  the  defend- 
ers' cell  (feba  « depth)  plus  the  effective  range  of  the  attackers' 
fire,  which  depends  upon  the  combat  environment.  To  be  precise, 
the  tactical  overlap  is  defined  as 

TO  = min  (feba  * depth  + td( [environment ]( loc )) , defdepth}. 

(Recall  that  cell  loc  is  the  engagement  location,  and  defdepth, 
defined  in  Section  5.1.1,  is  the  depth  of  the  defense.)  The 
intensity  of  combat  is  Indicated  by 

TI  = TO  / defdepth, 
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a number  between  0 and  1.  If  the  attackers  and  defenders  are 
colocated,  then  feba  = 1,  and  TI  = 1.  The  potential  losses  are 
scaled  by  TI: 

ploss  (atk(k ) ,irs  ) ■< — TI  * ploss  (atk(k)  ,lrs  ) , 
for  every  1 < k < natk  and  1 < irs  < nrs(sldeA),  and 

ploss  (def(k ) ,irs  ) •< — TI  * ploss  (def(k) , irs  ) 
for  every  1 < k < ndef  and  1 < irs  < nrs(sideD). 

The  losses  can  now  be  assessed.  Usually,  a unit  can  only 
lose  resources  that  are  actively  involved  in  combat.  If 
PRGRD  > .0001,  then  for  every  1 < k < natk,  [resources ] (atk( k) , irs ) 
is  reduced  by  the  quantity 

min  {ploss(atk(k) ,irs) , 

frinv( irs ,atk(k) ) » [resources] (atk(k) , irs) } 

for  every  1 < irs  < nrs(sideA).  But  if  PRGRD  < .0001,  the 
attackers  lose  everything:  for  every  1 < k < natk 

[resources]  (atk (k) , irs )•• — 0 

for  every  1 < irs  < nrs(sideA).  That  eliminates  the  possibility 
of  dummy  attacks,  in  which  the  attackers  have  no  ground-to-ground 
weapons  available  for  combat  and  suffer  no  losses.  If 
PRGRD  < 10,000,  then  for  every  1 < k < ndef,  [resources] (def(k) , irs) 
is  reduced  by  the  quantity 

min  {ploss (def(k) , irs ) , 

frinv( irs ,def ( k) ) * [resources] (def (k) , irs ) } 

for  every  1 < irs  < nrs(sideD).  If  PRGRD  > 10,000,  then  for 
every  1 < k < ndef 

[resources](def(k),lrs)  ■* — 0 
for  every  1 < irs  < nrs(sldeD). 

The  preceding  assessment  procedure  may  err  in  the  case  of 
personnel,  assuming  that  dpersr  and  dpersb  give  actual  personnel 
losses  associated  with  actual  materiel  losses,  rather  than  potential 
materiel  losses.  Inconsistency  occurs  when  and  only  when  the 
potential  loss  of  some  type  of  materiel  (given  by  ploss)  exceeds 
the  actual  (assessed)  loss  (which  cannot  happen  if  the  initial 
quantity  is  0,  for  then  the  potential  loss  is  0).  The  Inconsistency 
is  one  facet  of  a larger  phenomenon.  If  the  potential  loss  of 
some  type  of  materiel  exceeds  the  actual  loss,  the  force  to  which 


5-19 


I 

t 
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it  belongs  loses  a smaller  fraction  of  its  value  than  it  should, 
assuming  frdval  determines  that  fraction.  These  inconsistencies 
are  probably  small  in  magnitude  and  are  always  fleeting:  if  the 
potential  loss  of  some  type  of  materiel  exceeds  the  actual  loss, 
then,  barring  other  changes,  in  the  next  frame  none  of  it  will  be 
available  for  the  engagement  and  the  potential  loss  of  it  will  be 
0. 


5.2  FEBA  MOVEMENT 

Recall  that  each  engagement  has  its  own  FEBA,  measured  by 
the  variable  feba,  whose  primary  purpose  is  to  determine  when 
the  attackers  are  allowed  to  occupy  the  engagement  location. 

This  subsection  explains  how  any  given  engagement's  feba  is  up- 
dated at  the  end  of  a frame  to  reflect  the  combat  during  the 
frame.  The  notation  of  Section  5*1  remains  in  force. 

The  change  in  feba  from  the  start  of  the  frame  to  the  end 
of  the  frame  depends  on  the  attackers'  posture,  the  defenders' 
posture,  and  a force  ratio  that  Includes  the  contribution  of 
close  air  support  (CAS).  Air  support  is  assessed  at  the  start 
of  every  cycle,  as  Section  6 explains.  (A  cycle  consists  of  one 
or  more  frames.)  The  losses  of  ground-to-ground  weapons  inflicted 
by  CAS  are  recorded  for  use  by  the  combat  procedure.  For  every 
1 £ J £ nggwep(sldeD) , let  CASATK(J)  be  the  amount  of  the 
defenders'  type  J weapons  destroyed  by  air  strikes  made  (by  side 
sideA)  in  close  support  of  the  attackers;  of  course,  if  the 
attackers  received  no  CAS  in  the  cycle,  CASATK(j)  = 0.  For  every 
1 £ J £ nggwepisldek) , let  CASDEF(J)  be  the  amount  of  the  attack- 
ers' type  i weapons  destroyed  by  air  strikes  made  (by  side  sldeD) 
in  close  support  of  the  defenders.  These  losses  were  determined 
at  the  start  of  the  current  cycle,  and  are  assumed  to  be  spread 
uniformly  over  the  cycle.  Therefore,  to  find  CAS's  effect  on  the 
engagement  in  the  frame  now  ending,  CASATK  and  CASDEF  must  be 
divided  by  nframe,  defined  as  the  number  of  frames  in  a cycle. 

To  find  a force  ratio  that  reflects  both  the  ground  forces 
and  the  air  forces  in  the  engagement,  it  is  necessary  to  assign 
a value  to  CAS's  contribution  in  a way  consistent  with  the  way 
the  ground  values  are  determined.  The  antipotential  potential 
uiethod  facilitates  this.  Recall  that  the  attackers'  ground 
value  is 


m 

fgrd  = ersatk(i)  * vala(i), 

where  m = nggwep (sldeA)  (vala(i)  = 0 if  1 > m) . For  every 
1 < i < m 
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A(i,j)  * vald(J ), 


n 


vala(i)  = (1/alpha)  * 
where  n = nggwep  (.sideD) . Therefore, 


fgrd  = (1/alpha)  * 


n / m 

L ( E A(l, 
J = 1 \l=l 


j)  * ersatk(l))  » vald(J ) 


) 


The  sum  In  parentheses  is  side  sideD' s total  potential  loss  of 
type  j materiel  in  the  frame.  The  air  value  of  side  sideA  in 
the  engagement,  fair,  is  computed  the  same  way 

n 

fair  = (1/alpha)  * ^ (CASATK(j)/  nframe)  » vald(j). 

J = 1 

Analogously,  the  air  value  of  side  sideD  in  the  engagement  is 
defined  as 


gair  = (1/delta)  * 2^  (CASDEP(j)  / nframe)  x vala(J ) . 

j = l 

The  combined  ground-air  force  ratio  is 


FRGA 


fgrd  + fair 
ggrd  + gair 


Let  postA  be  the  attackers'  representative  posture  and  postD 
the  defenders'  representative  posture;  postA  and  postD  are 
defined  in  Section  5.1.3.  The  function  value 

vfeba  (FRGA,  postA,  postD,  sideA) 


is  the  velocity  of  an  engagement's  FEBA  when  the  combined  ground- 
air  force  ratio  is  FRGA,  the  attackers'  representative  posture 
is  postA,  the  defenders'  representative  posture  is  postD,  and 
the  attackers  belong  to  side  sideA.  (The  function  vfeba  is 
explicated  in  Section  5.4.)  Let 

temp  = vfeba(FRGA, postA, postD, sideA)  * tframe. 

This  number  may  be  negative.  If  febaO  is  the  value  of  feba  at 
the  start  of  the  frame,  then  at  the  end  of  the  frame 

feba  = min  {max  { f ebaO  + temp/depth , 0},  1}. 
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5.3  ELIMINATION  AND  RETREAT 


After  the  losses  In  one  frame  of  an  engagement  are  assessed, 
each  of  its  attackers  and  defenders  is  examined  to  see  if  it  is 
so  weak  it  should  be  eliminated.  The  evaluation  is  based  on  the 
resources'  "standard  values":  for  s = 1 or  s = 2 and 
1 < 1 < nrs(s),  rsvald(i,s)  is  the  "standard  value  of  a side  s 
type  1 resource  on  defense".  It  is  found  by  putting  the  resource 
on  defense  in  a nominal  engagement.  Let  si  = 1 and  s2  = 2.  For 
every  1 < i < nggwep{sl)  and  1 < J i nggwep{s2),  let 

DSTD(1,J)  = kdef(i,J,sl) 

nm 

* aggdef  , si)  / aggdef{l,V.,s\)  . 

k=l 

where  nm  = nmat(s2).  For  every  1 < 1 < nggwep{s2)  and 
1 < J < nggwepisl) , let 

ASTD(i,j)  = katk(i,J,s2) 

nm 

X ag g atk{.±, i ,s2)  / Y aggatk(l,k,s2)  , 

k=l 

where  nm  = nmat(sl).  The  subprogram  app  is  called  with  the  kill 
matrices  ASTD  and  DSTD  as  arguments;  it  returns  the  values  of 
the  side  si  resources  (on  defense),  which  define  rsvald( » , s 1 ) . 

The  values  of  the  side  s2  resources  (on  attack)  define 
rsvala(*,s2) — "the  standard  values  of  side  s2  resources  on 
attack" — which  are  used  to  resolve  mutual  attacks  (Section 
3.3.4).  To  compute  rsvald(*,s2) — the  Blue  resources'  standard 
values  on  defense — the  process  is  repeated  with  si  = 2 and 
s2  = 1. 

Let  unit  ibu  be  an  attacker  or  defender  in  the  engagement. 
Let  s = 1 if  it  belongs  to  Red  and  s = 2 if  it  belongs  to  Blue. 
Let  n = nrs ( s ) . Let 

n 

sv  = ^ toe(.butype(ih[i)  yl)  * rsvald(i,s), 

1=1 

n 

cv  = ^ [resources](ibu,i)  * rsvald(i,s). 

i=l 


cv  < vani8h{butype{Vou))  * sv  - 10  , 
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then  unit  ibu  is  eliminated:  it  is  assigned  the  mission  whose 
only  order  declares  -10  as  the  desired  posture. 

If,  at  the  end  of  a frame,  feba  > fehad  in  a given  engagement, 
the  defenders  are  declared  defeated,  and  the  combat  procedure 
calls  the  tactical  subprogram  haven  to  ascertain  whether  the 
defenders  have  a line  of  retreat.  To  be  admissible  as  a direction 
of  retreat,  a cell  must  be  active  and  adjacent  to  the  engagement 
location,  and  it  must  satisfy  the  following  conditions:  (1)  it 
contains  none  of  the  attackers  in  the  engagement;  (ii)  if  it 
contains  an  active  unit  belonging  to  the  attackers'  side,  then  it 
must  also  contain  an  active  unit  belonging  to  the  defenders'  side 
and  be  owned  by  the  defenders'  side.  If  the  game  design  variable 
haven. zoo  has  the  value  .true.,  a direction  of  retreat  can  also  be 
blocked  by  the  presence  of  attackers  in  cells  flanking  it.  To  be 
precise,  suppose  cell  i satisfies  all  the  preceding  conditions  for 
admissibility  as  a direction  of  retreat.  If  haven,  zoo  = .true.,  in 
order  to  be  an  admissible  direction  of  retreat,  cell  i must 
satisfy  the  additional  condition:  (ill)  if  cell  j is  adjacent 
to  both  cell  i and  the  engagement  location  and  it  contains  one 
of  the  attackers,  then  cell  i must  contain  an  active  unit  from 
the  defenders'  side  and  must  be  owned  by  the  defenders'  side. 

If  the  defenders  have  no  admissible  direction  of  retreat, 
they  are  eliminated.  If  they  have  an  admissible  direction  of 
retreat,  haven  selects  the  most  desirable  one.  Each  admissible 
direction  of  retreat  is  scored  as  follows: 

(1)  Initially,  let  its  score  be  0. 

(2)  If  it  is  exactly  two  cells  away  from  a cell  containing 
one  of  the  attackers,  let  its  score  be  -1. 

(3)  If  it  is  adjacent  to  a cell  (other  than  the  engagement 
location)  containing  one  of  the  attackers,  let  its 
score  be  -2. 

(4)  If  it  is  owned  by  the  attackers'  side,  decrease  its 
score  by  .5. 

(5)  If  it  is  owned  by  the  defenders'  side  and  contains  an 
active  unit  from  their  side,  increase  its  score 

by  1.8. 

(6)  Let  s = 1 if  the  defenders  are  Red  and  s = 2 if  they 
are  Blue.  Let  k = pthome(s) . If  the  cell  is  the 
k-th  rim  cell  of  the  engagement  location  increase 
its  score  by  .01. 

The  "rim  cells"  of  a given  cell  are  the  cells  adjacent  to  it. 

They  are  ordered  by  number,  from  lowest  to  highest.  For  example. 
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In  Figure  3.3  (page  3-6),  the  first  rim  cell  of  cell  6 is  cell 
2,  the  second  Is  cell  3»  the  third  is  cell  5,  the  fourth  is  cell 
7,  the  fifth  is  cell  9,  and  the  sixth  is  cell  10;  the  fourth  rim 
cell  of  cell  1 is  cell  2,  the  sixth  is  cell  5,  and  the  other  rim 
cells  of  cell  1 do  not  exist;  the  fifth  rim  cell  of  cell  1^  is 
cell  17. 

Let  cell  r be  the  admissible  direction  of  retreat  with  the 
highest  score;  ties  are  broken  by  minimizing  r.  Each  defender 
that  is  not  already  disengaging  is  forced  to  disengage  imme- 
diately toward  cell  r:  it  is  assigned  the  active  order 

desired  objective  = r, 

desired  posture  = pmapupipmapup(pmapup(pmapup(p)))) , 

where  p is  its  current  posture  (a  hold  posture).  Once  all  the 
defenders  are  disengaging,  the  attackers  are  allowed  to  occupy 
the  engagement  location,  as  Section  3-3.3  explains. 


5.4  THE  COMBAT  FUNCTIONS 

This  subsection  explains  the  functions  frinv,  zrarea,  freff, 
prep,  frdval,  and  vfeba,  which  the  subprogram  combat  invokes. 

They  are  piecewlse-af f ine  (loosely  speaking,  piecewise-linear ) 
functions  mapping  the  real  line  into  the  real  line.  Such  a 
function  is  specified  by  listing  points  in  its  domain — x(l), 
x(2) , . . . ,x(n) — and  its  value  at  each  of  these  points — y(l), 
y (2) , . . . ,y (n) . By  requirement,  x(l)  < x(2)  <...<  x(n).  The 
function  pafgen  evaluates  a piecewlse-af fine  function.  Let  w 
be  a real  number.  If  w < x(l),  then 


If  w > X (n) , then 


pafgen(w,y,x)  = y(l) 


pafgen(w,y ,x)  = y(n) . 


Suppose  x(l)  < w < x(n).  Let 


11=  max  {i:  x(i)<w,  l<i<n}, 

12  = min  {i:  x(l)  > w,  1 < i < n}. 


Then 


pafgen(w,y,x)  = 


(The  IDAHEX  function  pafgen  actually  has  an  additional  argument — 
n,  the  number  of  components  of  the  vector  x or  y.) 
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A similar  function,  paf,  is  used  to  evaluate  a plecewise- 
affine  function  whose  domain  is  the  nonnegative  reals.  Such  a 
function  is  specified  by  listing  its  value  at  0,  which  is  denoted 
yO;  listing  points  in  its  domain — x(l) , . . . ,x(n) ; and  listing  its 
values  at  these  points — y (1) , . . . ,y(n) . By  requirement, 

0 < x(l)  <...<  x(n).  Let  w be  a real  number.  Define  the  vector 
ylong,  with  n+1  components,  as  follows: 

ylong(l)  = yO, 

ylong(l+l)  = y(i)  for  1 < 1 < n. 

Define  the  vector  xlong,  with  n+1  components,  as  follows: 

xlong(l)  = xO, 


xlong(i+l)  = x(i)  for  1 < i < n. 

Then 

paf (w,y0,y,x)  = pafgen(w, ylong, xlong) . 

(The  IDAHEX  function  paf  actually  has  an  additional  argument — 
n,  the  number  of  components  of  the  vector  x. ) 


Resource  Availability  for  Combat  - frinv 


The  function  frinv,  as  called  by  the  combat  procedure,  has 
two  essential  arguments:  a unit  number,  ibu;  and  a resource 
type,  irsarg.  If  the  unit's  resources  of  type  Irsarg  are  equip- 
ment (weapons  or  transport),  frinv  returns  the  fraction  of  them 
that  are  available  for  combat;  equipment  is  available  for  combat 
if  and  only  if  its  requirements  for  support  and  protection  are 
met.  If  the  type  irsarg  resources  are  support  resources 
(supplies  or  personnel) j frinv  returns  the  fraction  of  them  that 
are  available  and  needed.  The  neutral  term  "fractional  involve- 
ment" designates  the  number  returned  in  either  case.  In  the 
process  of  determining  the  fractional  involvement  of  type  irsarg 
resources,  frinv  determines  the  fractional  involvement  of  every 
type  of  resources  in  unit  ibu.  Let  s = 1 if  unit  ibu  is  Red 
and  s = 2 if  it  is  Blue.  Let  fi(lrs)  be  the  fractional  involve- 
ment of  type  irs  resources  in  unit  ibu  for  every  1 < irs  < nrs(s). 
The  sequel  explains  how  it  is  determined. 

A unit  loaded  on  other  units  cannot  participate  in  combat: 
if  unit  ibu  is  a passenger  in  a stacked  task  force — i.e.,  if  the 
task  force's  transport  mode  is  positive  and  trptal{butype{lh\x)) 
equals  it — then  fi(i)  ^ 0. 

Henceforth,  assume  unit  Ibu  is  not  a passenger.  Given  that 
frinv  has  been  called  by  the  combat  procedure,  unit  ibu  must  be 
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engaged.  Other  units  from  Its  side  may  be  participating  in  the 
same  engagement;  frlnv  assumes  that  all  such  units  with  the  same 
location  as  unit  Ibu  perform  as  an  integral  whole,  sharing  their 
support  and  using  their  weapons  in  concert.  Let  L be  the  set 
of  every  unit  that  is  from  the  same  side,  participating  in  the 
same  engagement,  and  located  in  the  same  cell  as  unit  ibu.  Delete 
from  L every  unit  that  is  a passenger  in  a stacked  task  force. 

For  1 < irs  < nrs(s),  define  amount(irs)  as  the  total  quantity 
of  type  irs  resources  held  by  the  force  L: 

amount(lrs)  = 2^  [resources ]( 1 , irs ) . 
icL 

Let 

nsp  = nss(s)  + npers(s), 

the  number  of  types  of  side  s support  resources.  Suppose 
nsp  = 0.  Then  fl  is  determined  solely  by  considerations  of 
equipment  protection.  The  game  design  variable  pg  organizes 
equipment  into  protection  groups,  numbered  1,  2,...;  pg{±,s)  is 
the  protection  group  to  which  type  i equipment  of  side  s belongs. 
At  least  one  type  of  the  side's  ground-to-ground  weapons  should 
belong  to  protection  group  1.  Any  equipment  in  protection  group 
1 can  protect  itself  and  equipment  in  higher  protection  groups. 
Equipment  in  a protection  group  higher  than  1 cannot  protect  it- 
self, but  can  protect  equipment  in  protection  groups  higher  than 
its  own.  The  quantity  of  type  i equipment  that  a unit-quantity 
of  type  j equipment  can  protect,  provided  pgi^)  < pg(±),  is 
prcit(l,j,s)  by  definition.  Equipment  other  than  ground-to- 
ground  weapons,  although  it  may  conceivably  belong  to  protection 
group  1 and  be  able  to  protect  Itself,  is  assumed  to  be  unable 
to  protect  other  equipment — i.e.,  prot(i,j,s)  is  assumed  to  be 
0 if  j > nggwep(s) . In  the  present  case,  where  support  is 
ignored,  fi(i)  = 1 for  every  i such  that  pp(i,s)  = 1.  The 
fractional  Involvement  of  equipment  in  higher  protection  groups, 
if  any,  is  determined  Inductively.  Suppose  that  for  some 

k < max  {pp(i,s);  1 < 1 < nequlp(s)}. 
fi(i)  has  been  determined  for  every  i in  the  set 

I = {1:  pp(i,s)  < k,  1 < i < nequip(s)}. 

For  each  J such  that  pp(J,s)  = k + 1,  let 

QP(J)  = prot(J,l,s)  * fi(i)  * amount (i), 

the  quantity  of  type  J equipment  that  can  be  protected.  Set 


J 


fl(J)  = 


amount (j ) 


t 

I 


i 


imount  ( J ) } 


That  completes  the  Induction  step.  If  possible  k is  incremented 
by  1 and  the  step  is  repeated. 

Typically,  small  arms  belong  to  protection  group  1,  tanks 
to  group  2,  artillery  to  group  3>  and  ground-to-air  weapons  and 
transport  to  group  4.  Notice  that  protecting  one  type  of  equip- 
ment does  not  reduce  a weapon's  ability  to  protect  other  types 
of  equipment.  One  might  think  of  the  equipment  in  protection 
group  1 as  being  deployed  near  the  front  of  the  formation,  the 
equipment  in  protection  group  2 deployed  behind  it,  and  so  on, 
with  the  equipment  in  each  protection  group  acting  as  a screen 
for  the  equipment  deployed  behind  it. 

Henceforth,  assume  that  nsp  >0.  To  determine  fl(i)  for 
every  1 < i < nrs(s),  frlnv  implicitly  allocates  support  to  the 
various  types  of  resources.  The  allocation  is  reasonable,  but 
not  optimal:  it  does  not  maximize  the  force  L's  value  in  combat. 
It  should  not;  the  allocation  is  partly  prescriptive.  It  is 
designed  to  field  a balanced  combat  force — one  in  line  with 
stdtgti* ,s) , with  no  unprotected  equipment. 

Let 


neq  = nequip( s ) . 

For  every  1 < k < nsp  let 

suppt(k)  = amount (neq+k) , 

the  total  quantity  of  type  k support  held  by  the  units  in  L. 

If  personnel  are  played — i.e.,  if  npersis)  > 0 — the  quantities 
of  personnel  available  to  support  materiel  must  be  reduced  by 
overhead  requirements: 

suppt(k)-» — suppt(k)  - ^ ppoh{k,butype{i)) 

ieh 

for  every  1 < k < npersis).  (ppo4(k,j)  is  defined  as  the  over- 
head of  type  k personnel  in  a type  j battle  unit — a quantity 
that  is  independent  of  the  unit's  actual  size.) 

Let 

(0  if  s = 1, 

iO  = 

j nrs( 1 ) if  s = 2 . 
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The  game  design  datum  spdd(k,iO+lrs)  is  the  demand  of  a unit- 
quantity  of  side  s type  irs  resources  (1  < irs  < nrs(s))  for 
type  k support  (1  < k < nsp).^  The  IDAHEX  computer  program 
assumes  that  supplies'  demand  for  supplies  is  0 and  personnel's 
demand  for  personnel  is  0.  The  total  demand  of  the  force's 
resources  of  type  irs  for  support  of  type  k is  computed  as 

dd(k)  = amount(lrs)  « spcidC k, iO+lrs ) . 

Let  ss(k)  be  the  quantity  of  type  k support  allocated  to  the 
force's  type  irs  resources.  For  every  1 < k < nsp,  let 

sigma(k)  = paf  (ss(k)/dd(k) , frinv . f Oik, 10+±rs) , 

frinv. /(k,i0+irs,*),  frinv. x(s,*)) 

if  dd(k)  > 0,  and  let  slgma(k)  = 1 if  not.  The  fractional 
involvement  of  the  force's  type  irs  resources,  fi(irs),  is 
given  by 

fi(lrs)  = min  {sigma(k);  1 < k < nsp}. 

Thus,  allocation  of  support  to  each  type  of  resources  determines 
their  fractional  involvement.  To  be  sure  that  no  more  of  any 
type  of  support  is  allocated  than  is  available,  the  vector  alloc 
is  used  to  keep  track  of  the  allocation;  alloc(k),  for  1 < k < nsp, 
is  the  total  quantity  of  type  k support  allocated.  Initially, 
alloc  = 0. 

First,  personnel  are  allocated  to  supplies.  For  each 
1 < kpp  < npersis),  the  total  demand  for  type  kpp  personnel  by 
the  force's  supplies  is 

nssis) 

Q = ^ suppt(kss)  * spddi  nss(s)+kpp,  iO+neq+kss); 

kss=l 

the  demand  of  type  kss  supplies  alone  is 

dd  = suppt(kss)  » spddi  nss(s)+kpp,  iO+neq+kss) 

(1  < kss  < nssis));  the  allocation  of  type  kpp  personnel  to  type 
kss  supplies  is  chosen  as 

min  {dd,  dd  » (suppt(kpp)  / Q)}, 

^Equipment's  requirement  for  support  normally  should  include  the 
personnel  needed  to  operate  it  in  combat  and,  in  addition,  per- 
sonnel needed  to  keep  it  operational  (by  maintenance  and  repair, 
for  example).  With  respect  to  the  latter,  the  game  designer  must 
avoid  counting  personnel  requirements  twice — once  in  resources' 
requirements  ispdd)  and  once  in  overhead  ippoh) . 
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and  alloc(n88(s)+k;pp)  is  Increased  by  this  quantity.  As 
explained  above,  the  allocation  determines  fi(kss).  Only  that 
fraction  of  type  kss  supplies  are  available  for  allocation; 
redefine  suppt(kss)  for  every  1 < kss  < n88(s): 

suppt(kss)-< — fi(kss)  * suppt(kss). 

Next,  supplies  are  allocated  to  personnel,  but  fi(irs)  is 
set  to  1 for  each  nmat(s)  < irs  < nrs(s)  whether  or  not  the 
allocation  satisfies  personnel's  demand.  Record  the  allocation 
of  supplies: 

alloc(kss).< — alloc(kss)  + 
npers ( s ) 

amount (nmat ( s )+kpp ) * spdiCkss , iO+nmat ( s)+kpp ) . 

kpp=l 

(If  nss(s)  = 0 or  npersis)  = 0,  both  preceding  steps  are  vacuous.) 

Next,  support  is  allocated  to  equipment.  Let 

I = {ieq:  stdtgt(leq,s)  > 0,  1 < ieq  < neq}. 

If  i < neq  but  i ^ I,  fi(l)  is  set  to  0 and  never  changed.  If 

i e I and  amount(i)  = 0,  fl(i)  is  set  to  1 and  never  changed. 
Initially,  fi(i)  = 0 for  every  other  i e I.  It  is  increased  in 

small  Increments  by  increasing  the  support  allocated  to  each  type 

of  equipment  in  the  set  I.  Let  rgaln  be  a small  positive  number — 
.01,  for  example.  At  the  start  of  any  given  iteration  of  the 
algorithm,  let 


q(J ) = fi( J ) * amount (j ) 

for  every  j.  ( f i may  have  been  redefined  in  prior  iterations.) 
The  iteration  consists  of  performing  the  following  sequence  of 
operations  for  each  lei  for  which  amount (1)  > 0. 

Step  1:  If  pg{l,s)  = 1,  let  qp  = +”  and  go  to  Step  2. 

Let  P be  the  set  of  every  e I such  that  pg'(j,s)  < pp(i,s). 
Let 

qp  = ^ prot(i,j,s)  * q(J), 

JeP 

the  quantity  of  type  i equipment  that  can  be  protected  by 
the  equipment  presently  available  for  combat. 

Step  2 : Let 

qr  = rgain  « 8tdtgt{l,s), 


J 
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the  amount  by  which  q(l)  would  have  to  Increase  in  order 
to  Increase 


>. 


q(l)  / stdtgtilfS) 
by  the  amount  rgain.  Let 

qadd  = min  {qp,  qr} . 

For  every  1 < ksp  < nsp,  let  REQ(ksp)  be  the  amount  of 
additional  type  ksp  support  that  must  be  allocated  to 
type  i equipment  to  increase  q(i)  by  the  amount  qadd — 

, i.e.,  to  increase  fl(l)  by  the  amount 

qadd  / amount (i). 

If 

alloc(ksp)  + REQ(ksp)  < suppt(ksp) 

for  every  1 < ksp  < nsp,  then  allocate  the  support  and 

\ update  fi  and  q(i) : 

c 

I alloc(ksp)-* — alloc(ksp)  + REQ(ksp)  for  every  1 < ksp  < nsp, 

[ fid)-* — fi(i)  + qadd  / amount (i), 

\ qd)** — fid)  * amountd). 

i If  not,  fl(i)  cannot  be  increased. 

; Thus,  the  algorithm  tends  to  field  a balanced  combat 

force — i.e.,  it  strives  to  equalize 

fid)  » amount (1) 
stdtgt ( 1 , s ) 

over  every  i e I and  never  commits  unprotected  equipment  to 
combat. 

Support  not  actually  needed  by  resources  for  combat — i.e., 
unallocated  support — should  not  be  actively  Involved  in  combat 
(and  subject  to  enemy  fire).  The  final  step  reduces  the 
I fractional  involvement  of  support  that  is  in  surplus:  for 

[ every  neq  < irs  <.  nrs(s)  such  that  amount(irs)  > 0,  fi(lrs)  is 

redefined  as  | 

min  (fidrs),  alloc (Irs-neq ) / amountdrs)}. 

The  preceding  explains  the  derivation  of  frinv( irsarg,ibu) 
in  the  case  where  unit  ibu  is  engaged;  that  case  always  applies 
when  frinv  is  called  by  the  combat  procedure.  The  derivation 
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actually  involves  finding  the  fractional  Involvement  of  resources 
in  a set  of  units,  L,  that  share  their  support  and  use  their 
weapons  in  concert.  Sometimes,  for  a player’s  information,  it 
is  useful  to  find  the  fractional  involvement  for  a specified 
force  L,  rather  than  a force  inferred  by  frinv  from  the  argument 
ibu.  The  IDAHEX  entry  point  frinv  actually  has  two  additional 
arguments:  a vector,  list;  and  an  integer,  nlist.  If  ibu  < 0, 

frinv  constructs  the  set  L from  the  vector  list,  whose  first  nlist 
elements  must  be  the  identification  numbers  of  friendly  battle 
units;  frinv  then  proceeds  as  above  to  find  the  fractional 
involvement  of  resources  in  the  force  L. 


5.4.2  Area  of  Area  of  Influence  - zrarea 

The  function  value  zrarea (ibu)  is  the  area  of  the  area  of 
influence  of  battle  unit  ibu.  It  is  0 if  the  unit  is  Inactive. 
Assume  unit  ibu  is  active.  Let  s = 1 if  it  is  Red  and  s = 2 if 
it  is  Blue.  Its  current  value,  measured  in  terms  of  the  standard 
resource  values,  is 

nrs (s ) 

cv  = ^ rsvaldClrs , s ) * [resources ]( ibu, irs ) . 

irs  = l 

Its  value  at  toe  strength  would  be 
nrs (s ) 

sv  = rsvaldC  irs , s ) * toe  (iutype  ( ibu ) , irs  ) . 

lrs  = l 

The  size  of  its  area  of  influence  is  assumed  to  be  proportional 
to  the  size  at  toe  strength.  The  latter  depends  upon  the  unit’s 
type  and  posture  class.  Let  pc  be  the  unit’s  posture  class: 

zrarea(lbu)  = (cv/sv)  * aisize (butype (Ihu) , pc) . 


5.4.3  Battle  Unit  Effectiveness  - freff 


A battle  unit’s  effectiveness  may  depend  upon  the  density 
of  friendly  forces  in  its  location.  If  the  density  is  too  low, 
the  friendly  force  is  vulnerable  to  infiltration  and  turning 
maneuvers.  If  the  density  is  too  high,  the  friendly  force  is 
more  vulnerable  to  area  fire,  and  congestion  of  the  trafficable 
areas  reduces  ohe  maneuver  battalions’  tactical  mobility.  In 
many  models  the  degradation  of  effectiveness  due  to  high  density 
is  implemented  indirectly  by  a rule  limiting  the  number  of  units 
located  in  the  same  cell.  Since  units  may  vary  greatly  in  size, 
especially  late  in  the  game,  IDAHEX  uses  a more  flexible  method. 

I 
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Suppose  the  location  of  unit  Ibu,  an  active  battle  unit. 

Is  cell  1.  Let  F be  the  set  of  every  active,  friendly  unit 
located  In  cell  1,  Identified  by  number.  The  total  area  of 
their  areas  of  Invluence  Is 

A = ^ zrarea(J). 

jtP 

The  friendly  force  density  Is  A divided  by  the  cell  area;  let 
d equal  this  quotient.  Let  s = 1 If  the  units  In  F are  Red  and 
s = 2 If  they  are  Blue.  The  fractional  effectiveness  of  unit 
Ibu,  or  any  unit  in  F,  is 

freff(lbu)  = paf  (d,  freff.fO(s),  freff.f(s,*),  freff.xis,*)). 

Normally,  this  is  a number  in  the  interval  [0,1].  It  can  exceed 
1 only  if  freff.fOis)  > 1 or  /re//./(s,J)  > 1 for  some  J. 


5.4.4  Defensive  Preparation  - prep 

The  vulnerability  of  materiel  varies  with  the  time  its 
battle  unit  has  had  to  prepare  a defense.  Suppose  s = 1 or 
s = 2,  and  suppose  1 < 1 < nmat(s).  The  function  value 
prep(l,s,h)  is  the  factor  the  combat  procedure  applies  to  type 
1 materiel  belonging  to  a side  s unit  whose  defense  preparation 
time  equals  h. 

prep(i,s,h)  = pafgen  (h,  prep. /( 1 , s , * ) , prep.  a:(  s , * ) ) . 

Because  of  peculiarities  in  the  way  preparation  time  is 
calculated,  h may  be  negative.  The  game  designer  should  allow 
for  this  possibility  by  choosing 

prep.x(s,l)  < 0. 


5.4.5  Fraction  of  Value  Lost  - frdval 


This  function  finds  the  fraction  of  value  that  a side  in 
combat  loses  given  the  side's  posture  and  the  engagement’s 
ground  force  ratio.  Let  post  be  the  side's  posture  and  FR  the 
force  ratio.  Let  k = poff (post) . Let 

temp  = paf  (FR,  frdval.fOatkik), 

frdval. fatk(k,*) , frdval. x) 

if  post  > 4o  (the  side  is  the  attacker  in  the  engagement),  and 
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temp  = paf  (PR,  frdval.fOdef(k), 

frdval . fdefik , *) , frdval.x) 

if  post  < ^0  (the  side  Is  the  defender) . The  number  temp  gives 
the  fraction  of  value  lost  in  one  unit  of  time,  but  the  combat 
procedure  needs  to  know  the  fraction  lost  in  one  frame.  There- 
fore , 


frdval  (PR,  post) 


|1  - (1  - temp)**tframe;  temp  > 0 
^temp;  temp  < 0. 


The  combat  procedure,  which  calls  frdval,  interprets 
frdval(PR,post ) < 0 as  a signal  that  no  prediction  of  the 
side's  losses  should  be  made  from  the  force  ratio  and  therefore 
that  the  side's  losses  should  not  be  scaled  according  to  it. 


5.4.6  FEBA  Velocity  - vfeba 

The  function  value  vfeba  (PR,  pa,  pd,  sa)  is  the  velocity 
of  the  PEBA  (measured  by  depth  » feba)  in  an  engagement  in 
which  the  force  ratio  is  PR,  the  attackers  are  from  side  sa, 
the  attackers  are  in  posture  pa,  and  the  defenders  are  in 
posture  pd.  Let 


ka 


poffipa)  ; sa  = 1 

poffipa)  + vfeba. npa;  sa  = 2. 


The  offset  vfeba. npa  is  defined  by  the  entry  point  vfebaO.  If 
the  number  of  attack  postures  is  large  (l.e.,  if  npost(h)  is  close 
to  10),  it  may  be  necessary  to  increase  vfeba. npa  and  the  dimen- 
sions of  certain  variables  declared  by  vfebaO.  In  that  event, 
IDAHEX  will  advise  the  game  designer  with  a message  in  file  51 
(which  is  described  in  Section  8).  Let  kd  = poff (pd).  Then 

vfeba  (PR,  pa,  pd,  sa)  = 

paf  (PR,  vfeba.fO(ka,kd),  v feba. f(ka ,kd , a ) , vfeba. fr). 

This  number  may  be  negative. 

In  defining  vfeba. fO  and  vfeba. f the  game  designer  should 
keep  in  mind  that  the  attackers  have  already  been  charged  with 
the  time  needed  to  go  from  their  locations  to  the  engagement 
location,  and  if  they  occupy  the  engagement  location  and  then 
leave,  they  will  be  charged  with  the  time  needed  to  go  from  the 
engagement  location  to  their  new  locations;  the  movement  delay 
takes  care  of  unopposed  movement.  The  feba  velocity  is  used 
to  determine  an  additional  delay  caused  by  opposition.  Conse- 
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quently,  if  the  force  ratio  is  very  high,  the  feba  velocity 
should  be  very  high;  it  should  not  be  limited  by  the  unopposed 
movement  rate. 


6. 


AIR  SUPPORT 


At  the  start  of  every  cycle  (including  t = Unit),  each 
player  may  enter  air  strikes.  IDAHEX  contains  no  air  warfare 
model  and  therefore  has  no  way  of  ascertaining  what  air  assets 
a side  can  allocate  against  enemy  ground  forces.  It  assumes 
that  any  air  strike  a player  enters  is  within  his  side's  capa- 
bility. In  practice,  the  game  designer  adopts  either  of  two 
solutions:  he  gives  each  player  a list  of  the  air  assets 
available  in  each  cycle  for  use  against  enemy  ground  forces, 
or  he  runs  an  air  warfare  model  concurrently  with  IDAHEX.  The 
first  solution  is  suitable  when  the  course  of  the  air  war  is 
easy  to  predict — usually  because  one  side  clearly  dominates. 

Suppose  the  side  s player  (s  = 1 or  s = 2)  is  inputting 
an  air  strike.  His  first  line  of  input  tells  IDAHEX  the  "target 
cell"  and  the  "strike  role".  The  target  cell  is  the  cell  toward 
which  the  strike  is  directed.  The  strike  role  is  either  close 
air  support  (CAS)  or  air  interdiction  of  battle  units.  If  the 
strike  role  is  interdiction,  the  player's  next  input  line 
defines  the  four-component  vector  asprty,  which  is  a list  of 
the  four  positive  posture  classes  in  order  of  priority.  The 
next  input  line  sets  ascomp;  ascomp(i)  is  the  number  of  type  i 
aircraft  participating  in  the  strike  (1  £ i £ nactypis)). 

Suppose  the  air  strike  role  is  CAS.  If  there  is  no  engage- 
ment whose  location  is  the  target  cell,  the  player  is  warned 
and  no  strike  occurs.  If  such  an  engagement  exists,  let  V be 
the  set  of  every  enemy  unit  in  the  engagement,  identified  by 
unit  number.  If  the  enemy  units  are  the  defenders  in  the 
engagement,  and  if  at  least  one  of  them  is  in  a hold  posture, 
then  delete  from  V every  unit  in  a disengagement  posture. 

On  the  other  hand,  suppose  the  strike  role  is  Interdiction. 
Let  k be  the  smallest  Integer  such  that  asprty(k)  equals  the 
posture  class  of  some  active  enemy  unit  located  in  the  target 
cell.  Thus,  asprty(k)  is  the  highest  priority  posture  class 
that  appears  among  enemy  units  in  the  target  cell.  Let  pc  = 
asprty (k).  Define  V as  the  set  of  every  active  enemy  unit, 
identified  by  unit  number,  whose  location  is  the  target  cell 
and  posture  class  is  pc.  These  units  are  the  targets  of 
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the  strike.  Behind  this  definition  of  V is  an  implicit  assump- 
tion that  the  strike  aircraft  can  6nly  distinguish  enemy  units 
from  each  other  by  location  (cell)  and  posture  class. 

Let 

nw  = nagwepi s) . 

For  every  1 < iw  < nw,  the  amount  of  type  iw  air-to-ground 
weapons  in  the  strike  is 

n 

agwep(iw)  = ^ agtoad{l  ,lvi  ,s)  « ascomp(l) 
i=l 


where  n = naatyp(s)  . Let  v = 3 - s.  (Side  v is  the  enemy  of 
side  s.)  For  1 < j < nmat(v),  the  amount  of  type  j materiel 
in  the  target  battle  units  is 


grdra(J)  = 2-  [resources] ( i, J ) . 
ieV 

Let  env  be  the  environment  type  of  the  target  cell:  if  the 
target  cell  is  cell  1, 


env  = [environment] (1) . 

Choose  an  air-to-ground  weapon  type,  iw;  1 < iw  < nw.  For  every 
1 < j < nmat(v),  define 


aag( j ) 


^ aag'UtfeC  iw,  j , s ) if  the  strike  role  is  CAS 

and  side  s is  the  engagement 
attacker, 

aagde  f(.lv/,i  ,s)  if  the  strike  role  is  CAS 

and  side  s is  the  engagement 
. defender. 


aagred(ivf ,pc)  if  the  strike  role  is 
interdiction  and  s = 1 


aagbtuilvi ,pc)  if  the  strike  role  is 
interdiction  and  s = 2 


(Recall  that  pc  is  the  posture  class  of  the  target  battle 
units,  assuming  the  strike  role  is  Interdiction.)  For 
1 1 J 1 nmat(j),  the  fraction  of  fire  of  type  iw  weapons 


< 
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allocated  to  the  target  units'  type  J materiel  is  computed  as 


alphaCj ) 


aag(j)  » (grdrs(J)  / etdtgtCj .v) ) 
‘aag(l)  « (grdrs(i)  / 8tdtgt(l,v)) 


This  method  of  allocating  fire  is  analogous  to  the  method  used 
in  ground  combat. 

Choose  Ibu  e V and  1 < j < nmat(v).  The  goal  is  to  determine 
the  potential  destruction  of  type  J materiel  in  unit  ibu  by  the 
type  iw  weapons  in  the  strike,  denoted  K(lw,J,lbu).  In  parallel 
with  the  ground  combat  attrition  procedure,  this  quantity  is 
found  by  taking  a basic  kill  rate  and  applying  factors  that  each 
adjust  either  the  shooting  weapon's  lethality  or  the  target 
materiel's  vulnerability.  The  basic  kill  rate  depends  upon  the 
game  design  datum  kag'(lw,J,s)  and  the  allocation  of  fire.  The 
adjustment  factors  depend  upon  the  posture  class  of  unit  ibu — 
denoted  by  pc — and  the  target  cell  environment.  By  definition, 

K(iw,j,lbu)  = fcag(lw,j,s)  * faagpp(ivi,s,pc)  * foagopii  ,pc) 

* foagre(±vi,s,env)  * faagaeCi  ,v ,env) 

* Q, 

where  Q is  the  amount  of  fire  from  type  Iw  weapons  allocated  to 
type  j materiel  in  unit  ibu: 

Q = ^alpha(j)  » ( [resources] ( ibu ,j ) / grdrs(J))^  * agwep(lw). 

The  total  potential  loss  of  type  j materiel  by  all  the 
target  units  is 

nw 

V 2 K(iw,j,i) 
lev  lw=l 

If  the  strike  role  is  CAS  and  j < nggaep(v),  this  quantity  is 
recorded  in  the  array  casfx  for  later  use  by  the  combat  procedure. 

Choose  ibu  e V and  1 < j < nmat(v).  The  actual  loss  of  type 
j materiel  by  unit  ibu  is  computed  as  follows.  Initially,  set 
iw  = 1 . Let 


L = min  { K( iw, j , ibu) , [resources] ( ibu ,j  )} , 
and  reduce  the  unit’s  stocks  of  type  j materiel  by  that  quantity: 

[resources](lbu,  j ) ■• — [resources]  (ibu,  j ) - L. 
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This  loss  of  type  J materiel  implies  a loss  of  personnel.  If 
unit  ibu  is  Red,  then  for  each  1 < k < «pera(l),  the  number  of 
type  k personnel  in  the  unit  is  reduced  by  the  quantity 

min  {<iypretf(k,iw,  J ) * L,  [resources ] (ibu, nmat  (1  )+k) } . 

If  unit  ibu  is  Blue,  then  for  each  1 < k < npers(2),  the  number 
of  type  k personnel  in  the  unit  is  reduced  by  the  quantity 

min  {dgpiiZM(k,iw,  j ) * L,  [resources ]( ibu , nmat ( 2 )+k) } . 

If  iw  < nw,  iw  is  incremented  by  1 and  the  process  (starting 
with  the  definition  of  L)  is  repeated.  The  preceding  is  an 
efficient  way  of  computing  the  attrition,  but  leads  to  an 
unfortunate  anomaly:  the  way  the  air-to-ground  weapons  are 
ordered  can  affect  personnel  losses.  The  anomaly  arises  only 
when  the  battle  unit  has  some  type  j materiel  but  so  little 
that 


nw 

K(lw,j,lbu)  > [resources] (ibu, j ) 

ifel 

(before  [resources] (ibu,  j ) is  reduced).  Losses  of  materiel 
are  never  affected  by  the  ordering  of  air-to-ground  weapons. 
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7.  SUPPLIES  CONSUMPTION 


Every  unit's  consumption  of  supplies  Is  assessed  at  the 
end  of  each  frame.  Immediately  after  all  engagements  are 
evaluated  and  the  resulting  attrition  Is  assessed.  An  Inactive 
unit  (one  In  posture  class  -1  or  0)  consumes  no  supplies;  there- 
fore, the  rest  of  this  section  applies  only  to  active  units. 

Let  s = 1 or  s = 2.  If  nss(s)  = 0 — side  s supplies  are 
not  played — then  nothing  is  done.  Otherwise,  consumption  of 
supplies  by  side  s battle  units  in  a given  frame  is  determined 
as  follows: 

Let  unit  Ibu  be  a side  s battle  unit.  Let  1 < k < nss(s). 
Denote  the  unit's  demand  for  type  k supplies  by  D(ibu,k). 

Suppose  the  unit  is  not  engaged  or  it  is  a passenger  in  a stacked 
task  force.  In  the  latter  base,  let  pc  = 1;  otherwise  let  pc 
be  its  posture  class.  If  s = 1,  D(ibu,k)  is  defined  by 

nrs ( 1 ) 

D(ibu,k)  = tfvame  * ssuncr (k, Irs , pc ) * [resources ]( ibu, irs ) 

irs  = l 

If  s = 2 

nrs ( 2 ) 

D(ibu,k)  = 53  tframe  « ssuncfe ( k, irs ,pc ) * [resources ] (ibu, irs ) 

lrs  = l 

Thus,  every  resource  demands  supplies  according  to  its  unit's 
posture  class,  and  the  unit's  demand  is  the  sum  of  its  resources' 
demands.  Alternatively,  suppose  unit  ibu  is  engaged  and  is  not 
a passenger  in  a stacked  task  force.  Let  pp  be  its  posture,  and 
let 

r pp  - 19;  PP  > ^0 

P = 

I pp  - 9;  PP  < ^0. 

Let 

index  = mapps(s,p). 
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let 


For  every  1 < Irs  < nrs(s), 

lambda(lrs)  = frinv(irs ,ibu) , 

the  fraction  of  the  unit's  resources  of  type  irs  that  are  actively 
involved  in  combat.  Then 

nrs (s ) 

D(ibu,k)  = ^ tframe  * ssuact(k,irs , index  ) 

ii%^=l 

* (lambda(irs)  » [resources ] (ibu, irs )) 

nrs ( s ) 

+ ^ tframe  * ssvpes (k , irs , Index) 

1^=1 

* (1  - lambda(irs))  * [resources ] (ibu, irs ) . 

Because  the  rate  of  supplies  consumption  might  depend  strongly  on 
the  attack  or  defense  posture,  the  game  design  variables  eavaat 
and  ssvres  can  distinguish  different  attack  or  defense  postures. 
The  variable  mapps , which  induces  the  third  subscript  of  savaot 
and  ssvres y can  be  used  to  consolidate  attack  postures  (40-49) 
or  defense  postures  ( 10-29 )»  thereby  reducing  the  storage  require- 
ments of  ssvaat  and  ssvres. 

The  preceding  defines  any  battle  unit's  demands  for 
supplies.  Again  choose  a side  s battle  unit,  unit  ibu.  Suppose 
it  does  not  belong  to  a task  force.  Let  1 < k < ne8(s).  The 
unit's  present  stock  of  type  k supplies,  stk,  is  given  by 

stk  = [resources ]( ibu, nequlp ( s )+k) . 

The  quantity  of  type  k supplies  it  consumes  is  computed  as 

C = min  {D(ibu,k),  stk} 

(it  cannot  consume  more  than  it  has),  and  therefore  its  stock 
of  type  k supplies  at  the  end  of  the  frame  is  redefined  as 
follows  : 


[resources ] (ibu ,nequip (s  )+k)  — stk  - C. 

Alternatively,  suppose  unit  ibu  is  an  element  of  a task 
force  (possibly  the  only  element).  Let  TF  be  the  set  of  every 
unit  in  the  task  force,  identified  by  unit  number.  Choose 
1 <.  k < nss{s).  The  goal  is  to  determine  how  much  of  the  type 
k supplies  held  by  unit  ibu  are  consumed  in  the  frame.  The  task 
force's  total  demand  for  type  k supplies  is 
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dd  = X]  D(l,k). 

ieTP 

Its  total  stock  of  type  k supplies  is 

stk  = ^ [resources](i,nequip(s)+k) , 
ieTP 

The  amount  of  type  k supplies  consumed  by  the  task  force  is 
computed  as 

C = min  {dd,  stk}- 

Each  element  of  the  task  force  is  assessed  the  same  fraction  of 
its  stock  of  type  k supplies: 

[resources] ( i,nequip(s)+k) 

stk  - C 

,nequip(s)+k) 

for  every  i e TP  and,  in  particular,  for  1 = ibu.  Thus, 
the  elements  of  a task  force  share  their  supplies. 

After  assessing  supplies  consumption  by  a task  force  in 
a movement  posture,  IDAHEX  ascertains  whether  the  task  force  has 
exhausted  its  supplies  of  any  type  (assuming  nss{s)  >0).  If 
so,  the  task  force  might  lack  supplies  it  needs  in  order  to  move 
and  should  not  be  allowed  to  change  location.  IDAHEX  finds  what 
its  movement  delay  would  be  if  it  were  Just  starting  its  move- 
ment, in  its  present  posture.  If  that  delay  equals  or  exceeds 
10**9,  the  task  force's  mission  is  changed  to  a single  order 
specifying  10  as  the  desired  posture  and  its  present  location 
as  the  desired  objective — which  causes  the  task  force  to  abort 
its  movement  and  attempt  to  revert  to  a hold  posture  in  its 
present  location. 
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8.  COMMUNICATING  WITH  THE  lOAHEX  COMPUTER  PROGRAM 


IDAHEX  uses  the  following  files: 

filelO  - Red  player  input 

filell  - Red  player  output 

file20  - Blue  player  input 

file21  - Blue  player  output 

file50  - game  design  (input)  data 

flle51  - game  designer’s  output  file 

fileSO  - game  design  (input)  data 

The  program  references  a file  by  using  its  number — 10,  11,  20, 

21,  50,  51,  or  60 — as  the  data  set  reference  number  in  a FORTRAN 
formatted  read  or  write  statement  or  by  using  its  name  (fllelO, 
filell,  etc.)  as  the  file  name  in  a PL/I  get  or  put  statement. 

Pile  50  contains  all  the  game  design  data  except  the  values 
of  envmap,  rtemap,  and  barmap . Pile  60  contains  the  data  that 
define  envmap,  vtemap,  and  barmap  in  each  cycle.  The  format  and 
sequence  of  the  data  in  file  50  and  file  60  are  explained  in 
Section  9*  Pile  51  contains  IDAHEX's  interpretation  of  the  data 
in  file  50,  and  warning  or  error  messages  if  IDAHEX  questions 
the  correctness  of  the  data.  An  error  message  indicates  that 
IDAHEX  was  unable  to  interpret  the  input  data.  It  may  continue 
processing  the  game  design  data,  but  it  will  terminate  execution 
before  the  players  can  enter  air  strike  specifications  or  commands. 
A warning  draws  the  game  designer's  attention  to  a possible  error 
in  the  design  data;  execution  continues.  If  execution  is  allowed 
to  proceed  and  a game  is  played,  file  51  also  contains  a history 
of  the  game. 

The  game  design  datum  nprint  indicates  the  number  of  distinct 
data  sets  that  are  being  used.  If  nprint  = 1,  IDAHEX  expects 
files  50,  10,  and  20  to  be  associated  with  the  same  data  set 
(usually  card  reader  input)  and  all  the  output  files  to  be 
associated  with  the  same  data  set  (usually  high  speed  printer 
output).  If  nprint  = 2,  IDAHEX  expects  file  50  to  be  associated 
with  a different  data  set  than  files  10  and  20,  which  it  expects  to 
be  associated  with  the  same  data  set,  and  it  expects  file  51  to 
be  associated  with  a different  data  set  than  files  11  and  21, 
which  it  expects  to  be  associated  with  the  same  data  set.  If 
nprint  = 3,  IDAHEX  expects  every  file  to  be  associated  with  a 


8-1 


naaiiwiijiy 


! 

i 

i 

i 

I 


il 

i' 


. -tVX'  — f-.'TT— 


different  data  set.  No  matter  what  the  value  of  nprint,  file 
60  must  be  associated  with  a distinct  data  set  for  which  the 
rewind  operation  is  permitted.  Normally,  nprint  = 1 means  that 
IDAHEX  is  being  used  in  a batch  processing  mode;  nprint  = 2 
means  it  is  being  used  interactively  with  one  terminal,  which 
the  players  share;  and  nprint  = 3 means  it  is  being  used  with 
two  terminals,  one  for  the  Red  player  and  one  for  the  Blue 
player. 

By  using  the  save  command  (see  Volume  3>  Section  4),  a 
player  can  save  the  game  situation  in  an  unformatted,  rewindable 
file  that  he  designates  by  number.  At  least  one  file  should  be 
set  aside  for  this  purpose.  It  is  wise  to  set  aside  more  than 
one  because,  if  not,  every  save  will  necessarily  overwrite  the 
previous  one. 

The  file  associations  must  be  in  effect  when  IDAHEX  is 
Invoked.  The  following  MULTICS  commands  illustrate  how  the 
file  associations  are  established  when  IDAHEX  is  to  be  played 
from  exactly  one  terminal  {nprint  = 1). 

io  attach  filelO  syn_  user_input 

lo  attach  fllell  syn_  user_output 

io  attach  file20  syn_  user_input 

lo  attach  file21  syn_  user_output 

lo  attach  file50  vfile_  Slnal_dd 

io  attach  flle60  vfile_  Sinai_terrain_maps 

io  attach  file90  vflle_  Sinai_dd_unformatted 

io  attach  file91  vflle_  Slnal_game.l 

io  attach  file92  vfile_  Sinai_game.2 

io  attach  flle93  vfile_  Sinai_game.3 

set_cc  file 51  -on 

set_cc  filell  -on 

set_cc  flle21  -on 

line_length  115 

The  files  90,  91,  92,  and  93  identified  above  are  intended  as 
places  to  save  the  game  situation.  The  first  character  of  every 
line  output  to  files  11,  21,  and  51  is  a carriage  control  char- 
acter; hence,  the  files'  carriage  control  attribute  is  set  to  "on". 

The  IDAHEX  main  program  is  named  cgcm.  Invoking  it  invokes 
IDAHEX. 


n 


The  game  design  variable  iprint  governs  the  output's  level 
of  detail.  If  iprint  > 1,  file  51  will  contain  a complete  [ 

description  of  every  significant  change  in  a battle  unit's  i 

status.  If  iprint  > 5,  the  players  will  be  informed  of  every 
significant  change  in  a unit's  status.  If  iprint  > 7,  file  51  f 

will  contain  a complete  description  of  every  change  in  a unit's  j 
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status.  File  51  will  always  contain  a detailed  description 
of  every  engagement.  If  iprint  > 15,  the  players  will  receive 
the  same  description.  If  iprint  < 15,  they  will  not  be  informed 
of  an  engagement's  average  kill  matrices  (denoted  A and  D in 
Sections  5.1.1  and  5.1.2).  If  iprint  < 9,  they  will  not  be 
informed  of  the  values  of  the  attackers'  and  defenders' 
weapons  (Section  5.1.2).  If  iprint  < 5,  they  will  not  be 
informed  of  the  losses  in  the  engagement.  A value  of  9 is 
generally  best. 


9. 


GAME  DESIGN  DATA  INPUT 


The  game  design  data  are  read  from  files  50  and  60  in  a 
sequence  of  groups.  Section  9.1  describes  the  groups  of  data 
in  the  order  in  which  they  are  read.  The  description  of  a group 
consists  of:  (1)  a line  listing  the  variables  whose  values  the 
group  fixes  and,  on  the  right-hand-side,  the  name  of  the  IDAHEX 
entry  point  that  reads  the  group;  and  (2)  FORTRAN  statements 
Indicating  how  the  group  is  read  and  therefore  the  correct  order 
of  the  data  within  the  group.  The  FORTRAN  statements  do  not 
correspond  exactly  to  IDAHEX  source  code,  and  although  generally 
written  according  to  MULTICS  FORTRAN  language  conventions,  are 
not  necessarily  valid  source  code  for  any  compiler;  their  sole 
purpose  is  to  explain  how  the  contents  of  files  50  and  60  fix 
the  values  of  the  game  design  variables.  Contrary  to  FORTRAN 
convention,  the  FORTRAN  code  in  this  section  assumes  that  the 
statements  in  a do  loop  are  not  executed  even  once  if  the  lower 
bound  specified  in  the  do  statement  exceeds  the  upper  bound. 

Section  9*2  contains  a complete  example  of  files  50  and  60 
as  a sequence  of  lines  representing  card  images.  The  lines  are 
grouped  to  correspond  to  the  data  groups  of  Section  9.1 • The 
first  line  of  each  group  ends  with  the  code  number  used  for  the 
group  in  Section  9*1  (the  number  at  the  start  of  the  line  naming 
the  game  design  variables  and  the  entry  point). 


9.1  SEQUENCE  AND  FORMAT 

Game  design  variables'  names  are  not  italicized  in  this 
section.  The  only  variables  mentioned  that  are  not  game  design 
variables  are  do  loop  indices  and  the  following:  nnsyl  (fixed  by 
cgcm);  vtemp,  wtemp,  1,  j,  k,  side,  itemp,  name,  Jtemp,  temp,  old 
kap  (defined  in  cmbtO),  kdp  (defined  in  cmbtO),  nequlp,  nmat , nrs 

In  accordance  with  the  rest  of  the  manual,  some  variables' 
names  contain  two  components — for  example,  frinv.f,  frinv.x, 
freff.f.  Such  a variable  is  referenced  in  only  one  subprogram; 
it  takes  the  first  component  of  its  name  from  the  subprogram's 
name.  In  the  actual  IDAHEX  source  program,  the  variable's  name 
is  simply  the  second  component  of  the  two-component  name  used  to 
identify  it  in  this  manual. 


1 


The  following  format  statements  are  cited  by  many  read 
statements  in  this  subsection: 

2 format  (8il0) 

3 format  (8fl0.0) 

9.1.1  File  50 

1.  iprint,  nprint  cgcm 

read(50,2)  iprint,  nprint 


2.  tlnit,  tend,  tframe,  tcycle,  tpd,  delta  timeO 

read(50,3)  tinit,  tend,  tframe,  tcycle,  tpd,  delta 


3.  ncells,  nrankl  netO 

read(50,2)  r.cells,  nrankl 


^ . enameO  netO 

1 read(50,^)  1,  (name(k),  k = 1,  nnsyl) 

^ format  ^5,5x,6a8) 
if  (i.le.O)  go  to  6 
do  5 k = 1,  nnsyl 

enameO(i,k)  = nanB(k) 

5 continue 
go  to  1 

6 continue 


5.  nenv  netO 

read (50, 2)  nenv 


do  5 i = Ij  nenv 

read(50,4)  (ename(i,j),  j = 1,  nnsyl) 

4 format  (6a8) 

5 continue 


netO 
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7 . [basic_env] 

1 read(50,2)  i,  itenp 
if  (i.le.O)  go  to  5 
[basic_env](l)  = itenp 
go  to  1 
5 continue 


netO 


8.  mameO 


netO 


1 read(50,^<)  i,  (name(k),  k = 1,  nnsyl) 
^ format  (i5,5x,6a8) 
if  (i.le.O)  go  to  6 
do  5 k = i,  nnsyl 

mameO(i,k)  = name(k) 

5 continue 
go  to  1 

6 continue 


9.  bnameO 


netO 


1 read(50,4)  i,  (name(k),  k = 1,  nnsyl) 

4 format ( 15, 5x,6a8) 
if  (i.le.O)  go  to  6 
do  5 k = 1,  nnsyl 

bnaineO(i,k)  = naine(k) 

5 continue 
go  to  1 

6 continue 


10.  nr'tety 

read(50,2)  nrtety 


netO 


11.  mams 


netO 


do  5 i = 1,  nrtety 

read(50,4)  (mame(l,j),  j = 1,  nnsyl) 

4 format  (6a8) 

5 continue 


12.  nbarty 


netO 


read(50,2)  nbarty 


13.  bname  netO 

do  5 i = Ij  nbarty 

read(50,^)  (bname(lj),  j = 1,  nnsyl) 

4 format  (6a8) 

5 continue 


14.  [baslc_rtetype],  [basic_bartype]  netO 

1 read(50,2)  i,  (vtemp(k),  k = 1,3), 

(wtenip(k),  k = 1,3) 
if  (i.le.O)  go  to  5 
do  4 k = 1,3 

j = [ successor ](i,k) 
if  (j.le.O)  go  to  4 
[basic_rtetype](i,j ) = vteinp(k) 

[basic_bartype](i,j ) = wtenp(k) 

4 continue 
go  to  1 

5 continue 


15.  depth 

read (50, 3)  depth 

16.  iblul,  nsyl,  nutype 

read(50,2)  iblul,  nsyl,  nutype 

17.  npost 

read(50,2)  (npost(i),  1 = 1,4) 

18.  itrfp 

read (50, 2)  itrfp 

19.  nggwep,  ngawep,  ntrpt,  nss,  npers 

do  5 i = 1,2 

5 read(50,2)  nggwep(i),  ngawep(i), 

ntrpt(i),  nss(i),  npers(i) 
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netO 


buO 


buO 


buO 


buO 


20.  rsname 


do  5 k = 1,2 

do  5 1 = 1,  nrs(k) 

read(50,^)  (rsnaine(i,J ,k)  j 

4 format  (a5,lx,a5) 

5 continue 


= 1,2) 


21.  flag 


read(50,2)  (flag(i),  1=1,  nutype) 


22.  nrst,  lars 


do  5 1 = 1,  nutype 

5 read(50,2)  nrst(l),  (lars(J,l),  J = 1,  nrst(l)) 


23.  toe 


do  5 1 = 1,  nutype 
5 read(50,3)  (toe(l,J),  j 


= 1,  nrs(flag(l))) 


24.  alslze 


do  5 1 = 1,  nutype 
5 read(50,3)  (alslze(l,j ),  j 


- 1,11) 


buO 


buO 


buO 


buO 


buO 


25.  buname,  butype,  buloc,  bupost,  tentry,  [resources]  buO 

1 read(50,4)  1,  (vtenp(J),  J = 1,  nsyl) 

4 fonnat  (15,5x,7a8) 

If  (l.le.O)  go  to  10 
do  5 J = 1,  nsyl 

bunaine(l,j)  = vtenpC j ) 

5 continue 

read(50,6)  butype(l),  buloc(l),  bupost(l),  tentry(l) 

6 format  ( 3110, f 10.0) 

read(50,3)  ([resources](l,J ),  j = 1,  nrs(flag(butype(l)))) 
go  to  1 
10  continue 


26.  [owner]  buO 


read (50, 2)  border,  side 

rid  c;  1 = 1 hnrYlpr’ 


5 continue 
side  = 3 - side 
do  6 i = border  + 1,  ncells 


[owner] (1)  = side 

6 continue 

7 read(50,2)  1,  Itemp 
if  (i.le.O)  go  to  8 
[owner](i)  = iteirp 
go  to  7 

8 continue 


27.  pmapup,  pnapdn  waltO 

do  5 i = 10,  19 
pmapup(i)  = 20 

5 pniapdn(i)  = -10 
do  6 i = 20,  29 

pmapup(l)  = 30 

6 pmapdn(i)  = ^0 
do  7 1 = 30,  39 

pmapup(l)  = 40 

7 ptnapdn(l)  = 40 
do  8 i = 40,  49 

pmapup(i)  = 10 

8 pmapdn(i)  = 40 

10  read(50,2)  i,  itenp,  jtenp 
if  (I.le.O)  go  to  11 
pmapup(i)  = Itenp 
pmapdn(l)  = Jterrp 

go  to  10 

11  continue 


28.  ptran 

do  5 1 = 1,  4 

do  5 j = 1,  npost(l) 

5 read(50,3)  (ptran(l,j,k),  k = 9,  npost(i)) 

29-  diseng 

do  5 i = 1>  nutype 

5 read(50,3)  (dlsengd, j ) , J = 1,2) 

30.  airmove 

read(50,4)  (airmove(i),  i = 1,  npost(3)) 

4 foraat  (8£10) 

31.  mralr 

read(50,3)  (mrair(i),  i = 1,  nutype) 


waltO 


waitO 


waitO 


waitO 
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32.  bdelay,  rar 


waltO 


do  5 i = 1,  nutype 
do  5 J = 1,  npost(3) 

read(50,3)  (bdelay(l,J,k),  k = 1,  nbarty) 
read(50,3)  (mp(i,J,k),  k = 1,  nrtety) 

5 continue 


33-  tmreq,  tmcap,  ssreqm 
do  10  k = 1,  2 

read(50,3)  (trnreq(l),  1=1,  nrs(k)) 
read(50,3)  (tmcap(i),  i = 1,  nrs(k)) 
do  8 J = 1,  nrs(k) 

8 read(50,3)  (ssreqm(i,J ,k) , 1=1,  nss(k)) 

10  continue 


3^.  trptcl 

read(50,2)  (trptcl(i),  1=1,  nutype) 


35.  loadcl 

do  5 J = 1,  2 

5 read(50,2)  (loadcl(i,J ) , 1=1,  nrs(J)) 


36.  nlc,  Idsize,  Idcap 

do  10  k = 1,2 

read(50,2)  nlc(k) 
do  8 1 = l,nrs(k) 

8 read(50,3)  (ldsize(i,j ,k),  j = 1,  nlc(k)) 

read(50,3)  (ldcap(l,k),  1=1,  nrs(k)) 

10  continue 


37.  ftnr.fO,  flnr.f,  ftnr.x 
do  5 1 = 1,  nutype 

5 read(50,3)  fmr.fO(l),  (fmr.f(i,J),  j = 1,6) 

read(50,3)  temp,  (fYnr.x(J),  J = 1,6) 


38.  ssvncr 

do  5 1 = 1,  nss(l) 
do  5 J = 1,  nrs(l) 

5 read(50,3)  (ssvncr(i,J ,k),  k * 1,3) 
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waltO 


vgaitO 


waitO 


waitO 


ftnrO 


ssuseO 


39.  ssvncb 


ssuseO 


do  5 i = 1,  nss(2) 
do  5 J = 1,  nrs(2) 

5 read(50,3)  (ssvncb(l,J,k),  k = 1,3) 


40.  mapps,  ssvact,  ssvres  ssuseO 

do  10  side  = 1,2 
1 read(50,2)  1,  k 

if  (i.le.O)  go  to  10 
mapps(side,[kpost](i) ) = k 
read (50, 4)  old 
4 format  (£10) 

If  (old)  go  to  1 
do  6 i = 1,  nss(side) 

read(50,3)  (ssvact(l,J ,k) , J = 1,  nrs(side)) 
read(50,3)  (ssvres(l,J,k),  J = 1,  nrs(slde)) 

6  continue 
go  to  1 
10  continue 


41.  poff  cmbtO 

k = 0 

do  5 i = 10,  9 + npost(l) 
k = k + 1 
poff(i)  = k 

5 continue 

do  6 1 = 20,  19  + npost(2) 
k = k + 1 
poff(i)  = k 

6 continue 

do  7 i = 40,  39  + npost(4) 
k = k + 1 
poff(i)  = k 

7 continue 

do  8 i = 10  + npost(l),  19 

8 poff(i)  = poff(lO) 

do  9 i = 20  + npost(2),  29 

9 poff(i)  = poff (20) 

do  10  i = 40  + npost(4),  49 

10  poff(i)  = poff(40) 

11  read(50,2)  i,  k 

if  (i.le.O)  go  to  12 
if  U.le.29)  poff(i)  = max(k,poff(10)) 
if  ^.ge.40)  poff(i)  = max(k,poff(40)) 
go  to  11 

12  continue 
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i|2.  stdtgt 


cmbtO 


! t 


do  5 J = 1,  2 

5 read(50,3)  (stdtgt(l,j ),  1=1,  nrs(j)) 


i<3.  aggatk 

do  5 k = 1,  2 

do  5 1 = 1>  nggwep(k) 

5 read(50,3)  (aggatk(i,J,k),  j = 1,  nmat(3-k)) 


44.  aggdef 

do  5 k = 1,  2 

do  5 1 = 1>  nggwep(k) 

5 read(50,3)  (ag^ef(i,J,k),  J = 1,  nmat(3-k)) 


45.  katk 

do  5 k = 1,  2 

do  5 = 1,  nggwep(k) 

5 read(50,3)  (katk(i,j ,k) , j = 1,  nmat(3-k)) 


46.  kdef 

do  5 k = 1,  2, 

do  5 1 = 1>  nggwep(k) 

5 read(50,3)  (kdef(i,J  ,k) , J = 1,  nniat(3-k)) 


47 . f ckar 

kap  = 0 

do  5 1 = 40,  49 

5 kap  = max(poff(i) , kap) 
do  6 J = 1,  2 

do  6 i = 1,  nggwep(j) 

6 read(50,3)  (fckar(i, j ,k) , k = 1,  kap) 


48.  fckdr 

kdp  = 0 

do  5 i = 10,  29 
5 kdp  = tnax(poff(i),  kdp) 
do  6 J = 1,  2 

j do  6 1 = 1,  nggwep(J) 

i 6 read(50,3)  (fckdr(l,j ,k) , k = 1,  kdp) 
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cmbtO 


ciribtO 


cmbtO 


cmbtO 


cmbtO 


ciTibtO 


^9.  fckac 


cmbtO 


do  5 J = 1,  2 

do  5 i = 1,  nmat(J ) 

5 read(50,3)  (fckac(l,J ,k) , k = 1,  kdp) 


50.  fckdc 

do  5 J = 1,  2 

do  5 i = 1,  nmat(J ) 

5 read(50,3)  (fckdc(i, j ,k) , k = 1,  kap) 


51.  fckare 

do  5 j = 1,  2 

do  5 1 = 1,  nggwep(J) 

5 read(50,3)  (fckare(i,j,k),  k = 1,  nenv) 


52.  fckdre 

do  5 J = 1,  2 

do  5 1 = 1,  nggwep(J) 

5 read(50,3)  (fckdre(i,J ,k) , k = 1,  nenv) 


53-  fckace 

do  5 j = 1,  2 

do  5 i = 1,  nmat(J) 

5 read(50,3)  (fckace(i,j,k),  k = 1,  nenv) 


54.  fckdce 

do  5 J = 1,  2 

do  5 i = 1,  nmat(J ) 

5 read(50,3)  (fckdce(l,J,k),  k = 1,  nenv) 


cmbtO 


cmbtO 


cmbtO 


cmbtO 


cmbtO 


55.  barter  cmbtO 

do  5 J = 1,  2 

do  5 i = 1,  nggwepf,}) 

5 read(50,3)  (barler(ij  ,k) , k = 1,  nbarty) 
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m 


9 


56.  dpersr 


do  5 1 = 1,  npers(l) 
do  5 J = 1,  nggwep(2) 

5 read(|50,3)  (dpersr(i,j ,k),  k = 1,  nmat(l)) 


57.  dpersb 


do  5 i = 1,  npers(2) 
do  5 j = 1,  nggwep(l) 

5 read(50,3)  (dpersb(i,j,k),  k = 1,  nmat(2)) 


58.  td 

read(50,3)  (td(l),  i = 1,  nenv) 

59.  febab 

read(50,3)  (febab(i),  1=1,  nbarty) 

60 • febad 

read(50,3)  febad 

61.  vanish 

read(50,3)  (vanlsh(l),  1=1,  nutype) 

62.  frdval.fOatk,  frdval.fatk 

do  5 1 = 40,  39+npost(4) 

5 read (50, 3)  frdval.fOatk(poff(i)), 

(frdval.fatk(poff(l),j ),  j = 1,7) 

63.  frdval. fOdef , frdval.fdef 

do  5 1 = 10,  9+npost(l) 


5 read(50,3)  frdval. fOdef(poff(l) ) , 

(frdval.fdef(poff(l) J),  J 
do  6 1 = 20,  19+npost(2) 

6 read(50,3)  frdval. fOdef(poff(l)), 

(fVxlval.fdef(poff(l),J ),  j 
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1,7) 

1,7) 


cmbtO 


cmbtO 


cmbtO 


cmbtO 


cmbtO 


cmbtO 


frdvO 


frdvO 


X 


6^.  frdval.x 


frdvO 


read(50,3)  (frdval.x(i),  i = 1,7) 
4 format  (lOx,  YflO.O) 


65.  vfeba.fO,  vfeba.f 

vfeba.npa  = 6 
1 read(50,2)  1,  J 
if  (l.le.O)  go  to  5 
read(50,3)  vfeba.fO(poff(i),  poff(J)), 

(vfeba.f(poff(i),poff(J ),k),  k = 1,7) 

go  to  1 

5 read(50,2)  i,  j 

if  (i.le.O)  go  to  6 

read(50,3)  vfeba.fO(vfeba.npa+poff(i),  poff(J)), 

(vfeba.f(vfeba.npa+poff(i),  poff(j),k),  k 

go  to  5 

6 continue 


66.  vfeba.fr 

read(50,4)  (vfeba.fr(i),  i = 1,7) 
4 format  (lOx,  YflO.O) 


67.  ppoh 

do  5 J = 1,  nutype 

5 read(50,3)  (ppoh(i,j),  1=1,  npers(flag(J ) ) ) 


68 . spdd 

do  5 j = 1,  nrs(l) 

5 read(50,3)  (spdd(i,J),  i = 1,  nsp(i)) 


69.  frinv.fO,  frinv.f 

do  5 J =1,  nmat(l) 
do  5 1 = 1,  nsp(l) 

5 read(50,3)  frinv.fO(l,j ) 

(frinv.fUjJ ,1<),  k = 1,6) 


vfebaO 


= 1,7) 


vfebaO 


frinvO 


frinvO 


frinvO 


70.  frlnv.xd,*) 


frinvO 


read(50,^)  (frinv.x(l,i)»  1 = 1»6) 
4 format  (lOx,  7fl0.0) 


71.  spdd 

do  5 J = 1,  nrs(2) 

5 read(50,3)  (spdd(l,nrs(l)+j ),  i = 1,  nsp(2)) 


72.  frinv.fO,  frinv.f 

do  5 J = 1,  ninat(2) 
do  5 i = 1,  nsp(2) 

5 read(50,3)  (frinv.fO(i,nrs(l)+j ), 

(frinv.f(i,nrs(lHJ,k;,  k = 1,6)) 


73*  frinv.x(2,*) 

read(50,4)  (frinv.x(2,l) , i = 1,6) 
4 format  (lOx,  7fl0.0) 


74.  pg(*,l),  prot(*,*,l) 

read(50,3)  (pg(i,l),  1=1,  nequip(l)) 
do  5 1 = Ij  nequip(l) 

5 read(50,3)  (prot(i,j ,1),  J = 1,  nggwep(l)) 


75.  pg(*,2),  prot(*,*,2) 

read(r0,3)  (pg(i,2),  1=1,  nequlp(2)) 
do  5 1 = 1>  nequlp(2) 

5 read(50,3)  (prot(l,J,2),  j = 1,  nggwep(2)) 


76.  freff.fO,  freff.f,  freff.x 
do  5 1 = 1,  2 

read(50,3)  freff.fO(l),  (freff.f(l,J ),  j = 1,7) 
read(50,4)  (freff .x(l,J ) , j = 1,7) 

4 format  (lOx,  7fl0.0) 

5 continue 


frlnvO 


frlnvO 


frlnvO 


frlnvO 


frlnvO 


freffO 
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77.  prep.f,  prep.x 


prepO 


do  6 J = 1,  2 

do  5 i = 1>  nmat(J) 

5 read(50,3)  (prep.f(i,j ,k),  k=  1,7) 
continue 

read(50,3)  (prep.x( j,k),  k = 1,7) 

6 continue 


78.  nactyp,  nagwep 

do  5 i = 1,  2 

5 read(50,2)  nactyp(i),  nagwep(i) 


79.  kag 

do  5 k = 1,  2 

do  5 i = 1,  nagwep(k) 

5 read(50,3)  (kag(i,J,k),  j = 1,  ninat(3-k)) 


airO 


80.  fcagrp 

do  5 J = 1,  2 

do  5 i = 1,  nagwep(J) 

5 read(50,3)  (fcagrp(i,J ,k),  k = 1,4) 


airO 


8l.  fcagcp 

do  5 J = 1,  2 

do  5 i = Ij  nmatCj ) 

5 read(50,3)  (fcagcp(l,j ,k),  k = 1,4) 


airO 


82.  fcagre 

do  5 J = 1.  2 

do  5 i = 1,  nagwep(j) 

5 read(50,3)  (fcagre(l,J ,k),  k = 1,  nenv) 


83.  fcagce 

do  5 J = 1,  2 

do  5 i = 1,  nmat(j) 

5 read(50,3)  (fcagce(i,j ,k) , k = 1,  nenv) 


airO 


airO 


8^.  dgpred  airO 

do  5 k = 1,  nmat(l) 
do  5 i = 1>  npers(l) 

5 read(50,3)  (dgpred(l,J ,k),  J = 1,  nagwep(2)) 

85.  dgpblu  alrO 

do  5 k = 1,  nmat(2) 
do  5 i = 1,  npers(2) 

5 read(50,3)  (dgpblu(i,j ,k),  J = 1,  nagwep(l)) 

86 . agload  airO 

do  5 k = 1,  2 

do  5 i = 1,  nactyp(k) 

5 read(50,3)  (agload(i,j ,k) , J = 1,  nagwep(k)) 

87.  aagatk(*,*,l)  airO 

do  5 i = 1,  nagwep(l) 

5 read(50,3)  (aagatk(i,j ,1) , J = 1,  nmat(2)) 

88.  aagdef(*,*,l)  airO 

do  5 1 = 1,  nagwep(l) 

5 read(50,3)  (aagdef(i,j ,1),  j = 1,  nnat(2)) 

89.  aagatk(»,*,2)  airO 

do  5 i = 1,  nagwep(2) 

5 read(50,3)  (aagatk(i,j  ,2) , j = 1,  ninat(l)) 

90.  aagdef(»,*,2)  airO 

do  5 i = 1»  nagwep(2) 

5 read(50,3)  (aa^ef(i,j  ,2),  j = 1,  ninat(l)) 

91 . aagred  airO 

do  5 i = 1,  nagwep(l) 
do  5 j = Ij  nmat(2) 

5 read(50,3)  (aagred(i,j ,k) , k = 1,3) 
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airO 


92.  aagblu 


5 


do  5 i = 1.  nagwep(2) 
do  5 j = 1,  nmatd) 

i^ajd(50»3)  (aa^lu(i>J  jk) j k - 1» 


3) 


9 3 . haven . zoc , haven . pthome 


read(50,4)  haven. zoc, 

(haven. pthcaneCi),  1 - 
4 format  (£10,  2110) 


9.1.2  File  60 

The  follovdng  data  are  read  at  the  start  of  a cycle. 


94.  envmap 

1 read(60,2,end=5)  1,  J 
if  (i.le.O)  gp  to  5 
envmap(i)  = j 
go  to  1 
5 continue 


95.  rtemap 

1 read(60,2,end=5)  Ij  J 
if  (i.le.O)  go  to  5 
rtemap(i)  = J 
go  to  1 
5 continue 


96.  barmap 

1 read(60,2,end=5)  i>  J 
if  (i.le.O)  go  to  5 
barmap(i)  = j 
go  to  1 
5 continue 


havenO 


cgcm 


waitl 


waitl 


I 
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Before  the  start  of  a game,  IDAHEX  sets 

envraap(i)  = 1 for  every  i 
rtemap(l)  = i for  every  1 
barmap(i)  = 1 for  every  1, 

before  any  data  redefining  them  are  read.  At  the  start  of  each 
cycle,  including  the  first,  it  reads  file  60  for  redefinitions 
of  envmap,  rtemap,  and  barmap  as  described  above. 


9.2  SAMPLE  DATA 

This  subsection  illustrates  a complete  set  of  game  design 
data.  Each  line,  except  for  identification  codes  at  the  end, 
represents  an  80-column  card  image. 
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10.  GLOSSARY 


This  section  contains  an  alphabetical  glossary  of 
variables  and  functions  mentioned  in  this  volume.  For  each 
variable  such  that  array  dimensions  or  consistency  of  the 
game  design  data  implies  a finite  upper  or  lower  bound  on 
the  variable's  value,  that  bound  is  given;  "UB"  and  "LB"  are 
abbreviations  of  "upper  bound"  and  "lower  bound". 


Name 


aagatk(.t,i  ,k) 


aagbluit,^  ,k) 


aagdef(,i.,^  ,k) 


aagred(.±,  j , k) 


aggatk(.i,i  ,k) 


aggdefii, i ,k) 


agload{i,i ,k) 


airmove (i) 


Description 

fraction  of  fire  of  side  k air-to- 
ground  weapon  of  type  1 allocated 
to  enemy  materiel  of  type  j when 
enemy  materiel  belongs  to  engaged 
battle  unit  In  attack  posture 
LB  = 0 

fraction  of  fire  of  Blue  air-to- 
ground  weapons  of  type  1 allocated 
to  enemy  materiel  of  type  j when 
enemy  materiel  belongs  to  unengaged 
battle  unit  In  posture  class  k 
LB  = 0 

fraction  of  fire  of  side  k air-to- 
ground  weapons  of  type  1 allocated 
to  enemy  materiel  of  type  j when 
enemy  materiel  belongs  to  engaged 
battle  unit  In  hold  or  disengagement 
pos  tur e 
LB  = 0 

fraction  of  fire  of  Red  air-to- 
ground  weapons  of  type  1 allocated 
to  enemy  materiel  of  type  j when 
enemy  materiel  belongs  to  unengaged 
battle  unit  In  posture  class  k 
LB  = 0 

fraction  of  fire  of  side  k ground- 
to-ground  weapons  of  type  1 allo- 
cated to  enemy  materiel  of  type  j 
If  side  k Is  engagement  attacker 

fraction  of  fire  of  side  k ground- 
to-ground  weapons  of  type  1 allo- 
cated to  enemy  materiel  of  type  j 
If  side  k Is  engagement  defender 

notional  load  of  side  k air-to- 
ground  weapons  of  type  j on  side 
k aircraft  of  type  1 
LB  = 0 

true  If  1-th  movement  posture 
Implies  air  movement;  false  If 
no  t 


Ii£e 

real 


real 


real 


real 


real 


real 


real 


logical 
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of  a unit  of  type  i In  posture 
class  J if  its  resources  coincide 
with  toe(i  ,*) 

LB  = 0 

barter(i, J ,k)  factor  applied  to  katk(i,*,j)  if  real 

weapon  i belongs  to  battle  unit 
attacking  across  barrier  of  type  k 
and  engagement  feba  < febab (k) / depth 
LB  = 0 

barmapii.)  barrier  type  if  basic  barrier  integer 

type  is  i 

LB  = 0,  UB  » nbarty 

[bar type ]( i , j ) type  of  barrier  between  cell  i integer 

and  cell  j (0  signifies  no  bar- 
rier); undefined  unless  cells 
are  adjacent 
LB  = 0,  UB  = nbarty 

[basic _bartype2{i , i)  basic  type  of  barrier  between  integer 

cell  i and  cell  j (0  signifies 
no  barrier);  undefined  unless 
cells  are  adjacent 
LB  = 1,  UB  = nbarraw 

[basio_env'}  (1)  basic  environment  in  cell  i integer 

UB  = nenvraw 

[ias£e_rtetz/pe ] ( i , j ) basic  type  of  route  between  integer 

cell  i and  cell  j;  undefined 
unless  cells  are  adjacent 
LB  = 1,  UB  = nrteraw 

bdeZat/ ( 1 , j , k)  barrier  delay  for  a unit  of  real 

type  i in  j-th  movement  posture 
crossing  a barrier  of  type  k 
LB  = 0 

bname{±  ,-k)  description  of  barrier  type  i character 

bnameOii ,*)  description  of  basic  barrier  character 

type  i 


buloc  (1) 
butoa( 1 ) 


buname ( i , *) 


location  of  unit  i 


location  of  unit  1 (a  cell 
number)  at  t = tinit 
LB  = 1,  UB  = naells 


name  of  unit  i 
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integer 

Integer 


character 


J 


Name 

Description 

Type 

bupost (1) 

posture  of  unit  i 

Integer 

bupo8t{±) 

posture  of  unit  i at  t = Unit 

LB  = 0,  UB  = 19 

integer 

butype (±) 

type  of  unit  i 

LB  = 1,  UB  = nutype 

integer 

de  1 ta 

length  of  time  a unit  must  be 
in  movement  posture  before 
arrival  of  enemy  unit  at  its 
location  (point  of  origin) 
to  avoid  reversion  to  disengage- 
ment posture 

LB  = 0 

real 

depth 

distance  from  center  of  any  cell 
to  center  of  adjacent  cell 

LB  > 0 

real 

dgpblu(.i.,  i ,k) 

loss  of  Blue  personnel  of  type  1 
associated  with  destruction  of 
unit-quantity  of  Blue  materiel 
of  type  k by  Red  air-to-ground 
weapons  of  type  j 

LB  = 0 

real 

dgpred(±,i ,k) 

loss  of  Red  personnel  of  type  i 
associated  with  destruction  of 
a unit-quantity  of  Red  materiel 
of  type  k by  Blue  air-to-ground 
weapons  of  type  j 

LB  = 0 

real 

diaeng (i , 1) 

minimum  time  required  for  a type 
i unit  to  disengage 

LB  = 0 

real 

diaeng ( i , 2 ) 

factor  applied  to  movement  delay 
to  determine  additional  dis- 
engagement delay  imposed  on  type 

1 unit  disengaging  without  a 
rearguard 

LB  = 0 

real 

dpersb(i, j ,k) 

loss  of  Blue  personnel  of  type  i 
associated  with  destruction  of  a 
unit-quantity  of  Blue  materiel 

real 
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Name 


Type 


r ^ 

i 

I 

I 

i 


1 


dpersrd,  j ,k) 


Description 

of  type  k by  Red  ground-to- 
ground  weapons  on  type  j 
LB  - 0 

loss  of  Red  personnel  of  type  1 
associated  with  destruction  of 
a unit-quantity  of  Red  materiel 
of  type  k by  Blue  ground-to- 
ground  weapons  of  type  j 
LB  - 0 


real 


h 


ename ( 1 , *) 
enameO ( 1 , *) 

C environment ] ( 1) 

envmap (1) 

faagae(.i,i  ,k) 

faagap(i,2 .k) 

faagre(i,i ,k) 

/oagrp (l.j.k) 

fakaa{i,j ,k) 

[f ckac ] (1 , j , k) 


description  of  environment  type  1 character 

description  of  basic  environ-  character 

ment  type  1 

type  of  environment  In  cell  1 Integer 

LB  = 1,  UB  = nenv 

environment  type  If  basic  environ-  Integer 
ment  type  Is  1 
LB  = 1,  UB  = nenv 

factor  applied  to  kag {* , i , 3-i)  real 

If  target  battle  unit  Is  In 
environment  k 
LB  = 0 

factor  applied  to  kag {* ,1 ,3-2)  real 

If  target  battle  unit  Is  In 
posture  class  k 
LB  = 0 

factor  applied  to  kag(i,*,i)  real 

If  target  battle  unit  Is  In 
environment  k 
LB  = 0 

factor  applied  to  kag(i,*,2)  real 

If  target  battle  unit  Is  In 
posture  class  k 
LB  = 0 

factor  applied  to  ka t k ( * , 1 > 3 “ j ) real 

If  materiel  belongs  to  battle 
unit  In  posture  p (10  < p 1 
k = poff(p) 

LB  = 0 

factor  applied  to  ka t k ( * , 1 » 3- j ) real 

If  materiel  belongs  to  battle 
unit  In  posture  k;  It  equals 
fokaa(i , j . pof  f (k) ) 

LB  = 0 
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Name 


fokaae(i,j ,k) 


fokar(±,i ,k) 


[ f ckar ] (1, j , k) 


fakare(.±,i  ,k) 


fakda ( i, j , k) 


[fckdc] (i, j ,k) 


fakdae{i,i tk) 


fakdr(i,i ,k) 


[fckdr](i, j ,k) 


Description 

factor  applied  to  ka tk ( * , 1 , 3- j ) 
if  environment  In  engagement 
cell  is  type  k 
LB  = 0 

factor  applied  to  katk(i,*,j) 
if  weapon  belongs  to  battle 
unit  In  posture  p (40  f P £ 49); 
k = poff(p) 

LB  = 0 


factor  applied  to  katk(i,*,j) 
if  weapon  belongs  to  battle 
unit  in  posture  k;  it  equals 
fakar(.±,i  ,poff  (k)) 

LB  = 0 


factor  applied  to  katk(i,*,j) 
if  environment  in  engagement 
cell  is  type  k 
LB  = 0 


factor  applied  to  kdef ( * , i , 3-j ) 
if  materiel  belongs  to  battle 
unit  in  posture  p (10  $ P $ 29); 
k = poffip) 

LB  = 0 


factor  applied  to  kdef (*, i , 3-j ) 
if  materiel  belongs  to  battle 
unit  in  posture  k;  it  equals 
fc;kda(±,i  ,poff(k)) 

LB  = 0 


factor  applied  to  kdef (*, i , 3-j ) 
if  environment  in  engagement 
cell  is  type  k 
LB  = 0 


factor  applied  to  kdef(i,*,j) 
if  weapon  belongs  to  battle 
unit  in  posture  p (10  ^ p < 29); 
k = pof f (p) 

LB  = 0 


factor  applied  to  kdef(i,*,j) 
if  weapon  belongs  to  battle 
unit  in  posture  k;  it  equals 
fakdr(,i,i  ,poff  (k)) 

LB  = 0 


Type 

real 


real 


real 


real 


real 


real 


real 


real 


real 
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r ' 

Name 

4 V 

fakdreiiti ,k) 

febabit) 

febad 

flag{±) 

[floor] (a) 

j ) 

fmr .fO(i) 

fmr . X < j ) 

frdval . fatk(i, j) 

frdval . fdefH,  i) 


Description 

factor  applied  to  kdef(i,*,j) 
if  environment  in  engagement 
cell  is  type  k 
LB  = 0 

depth  of  attacker  penetration 
of  defender's  cell  at  which 
effect  of  type  i barrier  ceases 
LB  = 0,  UB  = depth 

degree  of  attacker  penetration 
of  defender's  cell  at  which 
defenders  must  disengage  and 
retreat  to  another  cell 
LB  = 0,  UB  < 1 

side  to  which  unit  of  type  i 
belongs 

largest  Integer  < a 

factor  applied  to  movement  rate 
of  type  i unit  when  its  ratio 
of  transport  capacity  to 
transport  demand  is  /mr.x(j) 

LB  = 0 

factor  applied  to  movement  rate 
of  type  i unit  when  its  ratio 
of  transport  capacity  to 
transport  demand  is  0 
LB  = 0 

ordinate  corresponding  to 
fmr.  for  any  1 

LB  = 0 

fraction  of  value  lost  by  attacker 
in  1 unit  of  time  when  attacker-to- 
defender  force  ratio  is  frdval .xi^) 
and  attacker  is  in  posture  p; 
i = poff(p) 

LB  = 0,  UB  = 1 

fraction  of  value  lost  by  defender 
in  1 unit  of  time  when  attacker- 
to-defender  force  ratio  is 
frdval. xd)  and  defender  is  in 
posture  p;  i = poffip) 

LB  = 0,  UB  = 1 

10-7 


1 

i 

TjSLEI 
real 

real 

real 

integer 

integer 
real 

real 

real 

real 


real 


Name 


frdval. fOatkii) 

frdvat . fOdefii) 

frdval. xii) 

freff.f(i,j) 

freff.fO(i) 

freff.x(.i,i  ) 

frinv.f( i , j , k) 


Description 

fraction  of  value  lost  by  attacker 
In  1 unit  of  time  when  attacker- 
to-defender  force  ratio  Is  0 and 
attacker  Is  In  posture  p; 

1 = poff(p) 

LB  = 0,  UB  = 1 

fraction  of  value  lost  by 
defender  In  1 unit  of  time  when 
attacker-to-def ender  force  ratio 
Is  0 and  defender  Is  In  posture 
p;  1 = poffip) 

LB  = 0 

ordinate  corresponding  to 
frdval . fatkii ,±)  and 
frdval. fdefij ,i)  for  any  j 
LB  = 0 

fractional  effectiveness  In  combat 
of  one  or  more  side  1 battle  units 
located  In  same  cell  If  total  area 
of  their  areas  of  responsibility 
divided  by  area  of  cell  equals 
freff.xii,]) 

LB  = 0 

fractional  effectiveness  In  combat 
of  one  or  more  side  1 battle  units 
located  In  same  cell  If  total  area 
of  their  zone  of  responsibility  Is 
LB  = 0 

ordinate  corresponding  to 
freff . f(±,i) 

LB  = 0 

fraction  of  type  r resources  avail- 
able for  combat  In  side  s battle 
unit  If  available  quantity  of 
type  1 support  resources  divided 
by  demand  for  type  1 support 
resources  equals  frinV.x(s,V.)’, 
j=rifs=l,  j=  nrs(l)+r  if 
s = 2 
LB  = 0 


Type 

real 


real 


real 


real 


real 


real 


real 
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Name 


Type 

real 


[ 

f 

\ 


frinv. fO(i, j ) 


frinv.x(i,j ) 


haven. pthome ( i ) 


haven. zoa 


iarsii,i ) 


ihluX 


iprint 


itvfp 


kagi±,i ,k) 


kap 


Description 

fraction  of  type  r resources 
available  for  combat  In  side  s 
battle  unit  if  available 
quantity  of  type  1 support 
resources  divided  by  demand  for 
type  i support  resources  equals 
0 ; j = r if  s = 1 , j = nrs(l)+r 
if  s = 2 
LB  = 0 

ordinate  corresponding  to 
f r Inv . f ( k, £ , j ) for  any  (k,£) 
associated  with  side  i 
LB  = 0 

preferred  direction  of  retreat 
for  side  i 
LB  = 1,  UB  = 6 

truth  value  of  "attacker's  zone 
of  control  extends  into  adjacent 
cells" 

absolute  index  of  i-th  resource 
on  list  of  resources  in  a unit 
of  type  j 

LB  = 0,  UB  = nrs(/Za^(j)) 

index  number  of  lowest-numbered 
Blue  unit 

LB  = 2,  UB  = nbumax 

level  of  detail  in  terminal 

output 

LB  = 0 

index  of  transfer  posture 
(10  < i < 19) 

LB  = 10,  UB  = 10  + npoatd) 

amount  of  enemy  materiel  of  type 
j destroyed  by  a single  side  k 
air-to-ground  weapon  of  type  i 
if  all  of  the  air-to-ground 
weapon's  fire  is  allocated  to 
enemy  materiel  of  type  j 
LB  = 0 

max  Lpoffii);  40  < i £ 49] 


real 


Integer 


logical 


integer 


Integer 


integer 


integer 


real 


integer 
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Name 

katki±,i .k) 


katk(i, j ,k) 
kdefii,i ,k) 


kdef(i,j,k) 

kdp 

[kpost ] (p) 
Idcapii,^ ) 

Idsize ( i , j , k) 

loadal ( i , j ) 

mappa  (i,  j ) 


Descript  Ion 

amount  of  enemy  materiel  of 
type  j destroyed  in  1 unit 
of  time  by  a single  side  k 
ground-to-ground  weapon  of 
type  i if  the  weapon  allo- 
cates all  its  fire  to  enemy 
materiel  of  type  j ; side  k 
is  the  attacker  in  the 
engagement 
LB  = 0 

t frame  * featfe(i,j,k) 

amount  of  enemy  materiel  of 
type  1 destroyed  in  1 unit 
of  time  by  a single  side  k 
ground-to-ground  weapon  of 
type  i if  the  weapon  allo- 
cates all  its  fire  to  enemy 
materiel  of  type  j ; side  k 
is  the  defender  in  the 
engagement 
LB  = 0 

t frame  * fede/(i,j,k) 

max  [po//(i);  10  £ i < 29] 

p-9ifp<40,  p-19 
if  p > 40 

load  capacity  of  resource 
of  type  1 belonging  to  side  j 
LB  = 0 

load  size  of  a single  side  k 
resource  of  type  i relative 
to  load  class  i 
LB  = 0 

load  class  of  a resource  of 
type  i belonging  to  side  j 
LB  = 0,  UB  = nlcmax 

pointer  used  to  reference  data 
on  supplies  consumption  in 
engaged  side  i battle  unit  in 
posture  p,  where  j = [kpost](p) 


Type 

real 


real 

real 


real 

integer 

integer 

real 

real 


Integer 


integer 


Name 


mr(i, j ,k) 

mpaip(i) 

naatyp  (.i) 
nagwep ( i) 

nbapty 

nae Its 

nenv 

nequip 

ngawep (I) 

nggwepi±) 

nlo (i) 


Description 

(see  asvaat  and  ssvpea) 

LB  = I,  UB  = ssuse.npsmax 

movement  rate  of  a unit  of 
type  1 In  j-th  movement 
posture  along  a route  type  k 
LB  = 0 

air  movement  rate  of  unit  of 
type  1 
LB  = 0 

number  of  side  1 aircraft  types 
LB  =0,  UB  = nacmax 

number  of  sides  1 alr-to-groUnd 

weapon  types 

LB  = 0,  UB  = nagwmx 

number  of  types  of  barriers 
(between  cells) 

LB  =0,  UB  = nbarrax 

number  of  cells  (largest 
Identification  number  of 
any  cell)  In  area  of  war 
LB  = 1,  UB  = ncelmx 

number  of  types  of  cell 

environments 

LB  = 1,  UB  = nenvmx 

number  of  types  of  side  1 
equipment  (nwep(i)  + ntppt(i)) 
LB  = 1 

number  of  types  of  side  1 
ground-to-air  weapons 
LB  = 0 

number  of  types  of  side  1 
ground-to-ground  weapons 
LB  = 1,  UB  = nggwmx 

highest  load  class  of  side 
1 resources 
LB  = 0,  UB  = 


real 


real 


integer 


integer 


Integer 


integer 


integer 


integer 


integer 


integer 


integer 


nlcmax 


Name 


[ 


nmar chp 
nmaC (1) 


nnsy  1 


npers (i) 


npost(i) 


nprint 


nrankl 


nrs ( 1) 


nrst ( i) 


nrte ty 


nsp ( i) 


nss ( i) 


Description 

max  {k:  airmoveik)  = false.} 

LB  = 1,  UB  = npo8t(3) 

number  of  types  of  side  i 
material  (nwep(i)  + ntrptii) 

+ nas ( i) ) 

LB  = 1,  UB  = nmatmx 

number  of  computer  double-words 
occupied  by  name  or  any  environ- 
ment, route,  or  barrier  type 

number  of  types  of  side  i 

personnel 

LB  = 0 

number  of  postures  in  posture 
class  1 

LB  = 1,  UB  = 10 

number  of  output  devices 
(printer  i terminals)  to 
be  used 

LB  = 1,  UB  = 3 

number  of  cells  in  first  row 
of  area  of  war 
LB  = 2,  UB  = noells 

number  of  types  of  side  i 
resources 

LB  = 1 , UB  = nrsmax 

number  of  types  of  resources 
that  a unit  of  type  i may  have 
LB  = 1,  UB  = nrsCflagit)) 

number  of  types  of  routes 
(between  cells) 

LB  = 1,  UB  = natmax 

number  of  types  of  side  i 
support  resources  («ss(i)  + 
npers{ 1) ) 

number  of  types  of  side  i 
supplies 

LB  = 0,  UB  = nssmax 


Type 

integer 


Integer 


integer 


integer 


integer 


integer 


integer 


integer 


integer 


1 nteger 


Integer 


integer 


<1 


I 

1 


1 
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Name 

nsyl 


ntrpt (1) 

nutype 
nwep ( i) 

[owner ] ( i) 
[owner] ( i) 

pmapdni i) 

pmapup ( i) 

Poffi±) 


ppoh(i,j) 

prep. fit, 2 ,k) 


prep.xit,^) 


Description 

number  of  computer  double- 
words  occupied  by  name  of  any 
unit 

LB  * 1,  UB  = 2 

number  of  types  of  side  i 
transport  vehicles 
LB  = 0,  UB  = ntrnmx 

number  of  types  of  units 
LB  * 1,  UB  = nutymx 

number  of  types  of  side  i 
weapons  inggwepH)  + ngawepii)) 

LB  = 1,  UB  = nwepmx 

1 if  Red  owns  cell  i,  2 if  Blue 

side  that  owns  cell  i at  t = tinit 

protection  group  to  which  side 
j resources  of  type  i belong 
LB  = 1 

first  posture  a unit  enters 
when  it  transitions  from  posture 
i to  a lower  posture  class 

first  posture  a unit  enters 
when  it  transitions  from  posture 
i to  a higher  posture  class 

offset  pointer  used  to  reference 
ground  combat  data  for  a unit  in 
posture  i (see  frdval . fatk, 
frdvat.fdef,  vfeba.f't 

number  of  overhead  type  i 
personnel  in  type  j battle  unit 
LB  = 0 

factor  applied  to  katk( * , i , 3- j ) 
if  defending  unit,  a member  of 
side  j,  is  credited  with  defense 
preparation  time  equal  to  prep.x(j, 
LB  = 0 

ordinate  corresponding  to 
prep. /(k, i , j ) for  any  k 


Type 

integer 

integer 

integer 

integer 

integer 

integer 

integer 

integer 

int  eger 

integer 

real 

real 

k) 

real 
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Name 

Description 

Type 

prot(itj ,k) 

amount  of  side  k resources  of  type 
i that  a side  k ground-to-ground 
weapon  of  type  j can  protect 

LB  = 0 

real 

ptran ( i , j , k) 

time  required  to  transition  from 
j-th  posture  in  posture  class  1 to 
k-th  posture  in  posture  class  i 

real 

[resources] ( i , j ) 

quantity  of  resources  of  type  j 
in  unit  i (classif ication  of 
resources  by  type  depends  on 
unit ' s side) 

real 

\_resouvoes  ] (1 , j ) 

quantity  of  resources  of  type  j 
in  unit  1 at  t = Unit 

LB  = 0 

real 

pname ( 1 , *) 

description  of  route  type  i 

character 

rnameO (±, *) 

description  of  basic  route  type  i 

character 

psname ( i , * , j ) 

description  of  side  j resource 
type  i 

character 

r svala (i , j ) 

standard  value  of  side  j type  i 
resource  on  attack 

real 

r svald (1 , j ' 

standard  value  of  side  j type  1 
resource  on  defense 

vtemap ( i) 

route  type  if  basic  route  type 
is  1 

LB  = 1,  UB  = nrtety 

integer 

[rtetype](l,  j ) 

type  of  route  between  cell  i 
and  cell  j;  undefined  unless 
cells  are  adjacent 

LB  = 1,  UB  = nrtety 

integer 

spddCi, j) 

demand  for  type  i support 
resources  by  a unit  quantity 
of  type  r resources;  j = r if 
resources  belong  to  Red  battle 
unit;  j = nrs(l)+r  if  resources 
belong  to  Blue  battle  unit 

LB  = 0 

real 

sareqm ( i , j , k) 

quantity  of  side  k supplies  of  type  real 

1 required  by  a side  k resource 
of  type  j in  order  to  move 

LB  = 0 

10-1^ 


Name 


Description 


Type 


sayaetd,  j ,k) 


quantity  of  type  i supplies 
consumed  in  one  unit  of  time  by 
a type  j resource  actively 
involved  in  ground  combat; 
supplies  and  resource  belong 
to  a battle  unit  from  side  s in 
posture  p;  k = mapps (s , [kpost ] (p) ) 
LB  = 0 


real 


ssvnab ( i , j , k) 


amount  of  type  i supplies 
consumed  in  one  unit  of  time 
by  a type  j resource  in  a Blue 
battle  unit  in  posture  class  k; 
1 < k < 3 
LB  = 0 


real 


ssvnop ( i , j , k) 


amount  of  type  i supplies 
consumed  in  one  unit  of  time 
by  a type  j resource  in  a Red 
battle  unit  in  posture  class 
k;  1 < k < 3 
LB  = 0 


real 


ssvres ( i , j , k) 


consumption  of  type  i supplies 
in  one  unit  of  time  by  a type  j 
resource  not  actively  involved 
in  combat  but  in  an  engaged 
battle  unit;  battle  unit  belongs 
to  side  s and  is  in  posture  p; 
k = mapps ( s , [kpos t ] (p ) ) 

LB  = 0 


real 


stdtgt{±,i) 


quantity  of  resource  i in  a 
standard  side  j ground  force 
LB  = 0 


real 


[successor] (1, j ) 


j-th  successor  of  cell  i 
(1  < j < 3) 

current  game  time  (t  = tinit 
at  start  of  game) 


integer 


real 


toy  ate 


td{±) 


length  of  cycle 
LB  = tpd 

depth  of  defender's  tactical 
zone  when  environment  in 
engagement  cell  is  type  i 
LB  = 0 
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Name 

tend 

tentry ( i) 

tentry ( i) 

t frame 
tinit 
toed,  j) 

tpd 

trnsap ( i , j ) 

trnreq ( 1 , j ) 

trptal ( i) 

vanishi 1 ) 


Description 

time  at  which  game  ends 
LB  = tinit 

time  at  which  unit  1 entered 
location  and  posture  class 
it  is  in  at  start  of  game 

virtual  time  at  which  unit  i 
entered  its  present  posture 
class 

length  of  frame 
LB  = 0,  UB  = tpd 

time  at  start  of  game 
LB  = 0 

planned  effective  quantity 
of  type  j resources  in  a 
unit  of  type  i 
LB  = 0 

length  of  period 

LB  = t frame,  UB  = toy  ale 

transport  capacity  of  each 
side  j resource  of  type  i 
LB  = 0 

transport  requirement  of 
each  side  j resource  of 
type  i 
LB  = 0 

transport  class  of  a unit 
of  type  i 
LB  = 0 

fraction  of  standard  value 
at  which  battle  unit  of 
type  i vanishes 
LB  = 0,  UB  = 1 


Type 

real 

real 

real 

real 

real 

real 

real 

real 

real 

integer 

real 


Name 


vfeba.  fO(.l,i) 


vfeba.  ,k) 


vf eba . npa 


vfeba.frii) 


Description 


signed  distance  of  FEBA  movement 
in  1 unit  of  time  if  attacker-to- 
defender  force  ratio  is  0, 
attacker  is  in  posture  p",  and 
defender  is  in  posture  p' ' ; 
j = poff  (p")i  i = poff  ip')  if 
attacker  is  Red;  1 = vfeba. npa 
+ poff(p')  if  attacker  is  Blue 


IJLSA 

real 


signed  distance  of  FEBA  movement 
in  1 unit  of  time  if  attacker-to- 
defender  force  ratio  is  vfeba. frii), 
attacker  is  in  posture  p' , defender 
is  in  posture  p" ; j = poffip"); 
i = poffip')  if  attacker  is  Red; 
i = vfeba. npa  + poffip' ) if 
attacker  is  Blue 
LB  = 0 


real 


maximum  number  of  attack  postures 
subprogram  vfeba  can  accommodate 
given  current  array  dimensions 


integer 


ordinate  corresponding  to 
vfeba. fii ,k,i)  for  any  (j,k) 
LB  = 0 


real 
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INDEX  OF  VARIABLES 


aagatk 

6-2,8-15,  10-2 

aagb lu 

6-2,9-16,10-2 

aagdef 

6-2,9-15,10-2 

aagred 

6-2,9-15,10-2 

aggatk 

5-4,5-22,9-9,9-15,  10 

aggdef 

5-7, 9-9,  10-2 

agload 

6-2,9-15,10-2 

avrmove  3-9,3-10,3-17,3-19, 

9-6,10-2 

aisize 

5-31,9-5,10-3 

barier 

5-6,5-18,9-10, 10-3 

barmap 

2-3,2-5,8-1,9-16,9-17 
] 0-3 

[bartype]  2-3,2-5,3-11,3-17, 

3-20, 5-5, 10-3 

\_basio_bartype'\  2-3, 2-5, 9-4, 

10-3 

ibas-La_ 

eny]  2-3, 2-5, 9-3, 10-3 

\_basia_ 

rtetype']  2-3, 2-5, 9-4, 

10-3 

bde lay 

3-12,3-12,3-15,3-17, 

3-20,3-21,9-7,10-3 

bname 

9-4,  10-3 

bnameO 

9-3,  10-3 

buloc 

1-2, 9-5,  10-3 

buloQ 

1-2,  10-3 

buname 

9-5,  10-3 

bupost 

9-5  , 10-4 

bupost 

10-4 

butype 

2- 6,2-10,2-11,3-11-- 

3- 21 ,4-l--4-9, 5-22, 
5-25,5-27,5-31,9-5, 
10-4 

de  1 ta 

3-26,9-2,10-4 

depth 

2-l,3-12--3-14,5-2,5-6 

5-7,5-18,5-21,9-4,10-4 

dgpblu 

6-4,9-15,  10-4 

dgpred 

6-4,9-15,  10-4 

diseng 

3-20,3-21,9-6,10-4 

dpersb 

5-9,5-19,9-11,10-4 

dpersr 

5-8,5-9,5-19,9-11, 

10-5 

ename  9-2 , 10-5 
enameO  9-2 , 10-5 
[environment]  2-3, 5-5, 5-7, 
5-18,6-2,10-5 

envmap  2-3,2-5,8-1,9-16,9-17, 
10-5 

faagae  6-3,9-14,10-5 
faagap  6-3,9-14,10-5 
faagre  6-3,9-14,10-5 
foagrp  6-3,9-14,10-5 
fakaa  5-18,9-10,10-5 
[ f ckac  ] 5-5,10-5 

fakaae  5-5,5-18,9-10,10-6 
fakar  5-5,5-18,9-9,10-6 
[fckar]  5-5,10-6 
fakape  5-5,5-7,5-18,9-10,10-6 
fakdo  5-7,5-18,9-10,10-6 
[fckdc]  5-7,10-6 
fokdoe  5-5,5-7,5-18,9-10,10-6 
fakdr  5-7,5-18,9-9,10-6 
[fckdr]  5-7,10-6 
fakdre  5-5,5-7,5-18,9-10,10-7 
febab  5-6,9-11,10-7 
febad  5-2,5-23,9-11,10-7 
flag  9-5,9-12,10-7 
fmr.f  3-12,9-7,10-7 
fmr.fO  3-12,9-7,10-7 
fmr.x  3-12,9-7,10-7 
frdval. fatk  5-32,9-11,10-7 
fpdval.fdef  5-33,9-11,10-7 
frdval. fOatk  5-32,9-11,10-8 
frdval. fOdef  5-33,9-11,10-8 
frdval. X 5-32,5-33,9-12,10-8 
freff.f  5-32,9-13,10-8 
freff.fO  5-32,9-13,10-8 
freff.x  5-33,9-13,10-8 
frinv.f  5-28,9-12,9-13,10-8 
frinv.fO  5-28,9-12,9-13,10-9 
frinv.x  5-28,9-13,10-9 
haven. p thorn e 9-16,10-9 
haven. zoo  5-23,9-16,10-9 
iars  2-10,4-5,9-5,10-9 
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ihlul  9-4,10-9 
iprint  8-2,8-3,9-2,10-9 
itrfp  3-4,3-7,3-25,4-5,4-8, 

4-9,9-4,10-9 
kag  6-3,9-14,10-9 
kap  9-9 , 10-9 
katk  1-2,5-1,9-9,10-10 
katk  1-2, 5-2--5-5, 5-18, 5-23, 
10-10 

kdef  5-2,5-3,5-5,9-9,10-10 
kdef  5-2,5-3,5-7,10-10 
kdp  9-9,10-10 
[kpost]  9-8,10-10 
Idaap  3-15,9-7,10-10 
Idaize  3-16,9-7,10-10 
loadol  3-15,9-7,10-10 
mapps  7-1,7-2,9-8,10-10 
mr  3-11, 3-12, 3-14--3-16, 3-20, 

3-21,9-7, 10-11 

mpair  3-9.3-18.3-19,9-6,10-11 


iowner']  3-24,10-13 
pg  5-26,5-29,9-13,10-12 
pmapdn  3-1  — 3-5,  3-7,3-24,3-26, 

4-2,5-24,9-5,10-13 
pmapup  3-1--3-5 , 3-7, 3-24 , 3-26 , 
4-2,5-24,9-5,10-13 
poff  5-5,5-7,5-33,9-8,9-11, 
9-12,10-13 

ppoh  5-27,5-28,9-12,10-13 
prep,  f 9-14, 10-13 
prep.x  5-32,9-14,10-13 
pvot  5-26,5-29,9-13,10-14 
ptran  3-10,9-6,10-14 
[resources]  2- 1 1 , 3- 1 1 , 3- 1 4--  ; 

3-18, 3-26, 4-6--4-8, 

5-35-4,5-7,5-8, 

5- 19,5-22,5-25, 

6- 2--6-4, 7-1  — 7-3, 
10-14 

{.resources'^  2-10-2-11,9-5,10-14 


nactyp  6-1,6-2,9-14,10-11 

rname 

9-3, 10-14 

nagwep  6-2,9-14,10-11 

rnameO 

9-3, 10-14 

nbarty  9-4 , 10-11 

rsname 

9-5,10-14 

naells  2-1,2-3,3-10,3-17,9-2, 

rsvala 

3-28,5-22, 10-14 

10-11 

rsvald 

3-28,5-22, 10-14 

nenv  9-2 , 10-11 

rtemap 

2-3,2-5,5-15,8-1,9-16, 

nequip  5-26,5-27,7-2,7-3,9-13, 

9-17, 10-14 

10-11 

[rtetype]  2-3,3-11,3-14,3-16, 

ngawep  9-4 , 10-11 

3-21, 10-14 

nggwep  5-3,5-7,5-8,5-11,5-20, 

spdd  5 

-28,9-12,9-13,  10-14 

5-22,5-26,6-3,10-11 

ssreqm 

3-11,3-13,3-15,3-17, 

nla  9-7,10-11 

3-18,9-7, 10-14 

nmarchp  10-12 

ssvaat 

7-2, 9-8, 10-15 

nmat  5-8,5-32,10-11 

ssvnab 

7-1,9-8,10-15 

nnsyl  9-2,9-3,10-12 

ssvnar 

7-1 , 9-7,10-15 

npers  5-8,5-9,5-26,5-27,5-29, 

ssvres 

7-2, 9-8, 10-15 

6-4, 9-4, 10-12 

s tdtgt 

5-4,5-7,5-29--5-31 ,6-3 

npost  2-7,3-4,3-7,3-10,4-2, 

9-9, 10-15 

5-33,9-4,10-12 

[successor]  2-1,9-4,10-15 

nprint  8-1,8-2,9-2,10-12 

t 2-11 

, 10-15 

nrankl  2-1,9-2,10-12 

toy  ale 

9-2, 10-15 

nrst  2-10,4-5,9-5,10-12 

td  5-18,9-11,10-15 

nrtety  9-3,  10-  12 

tend  2 

-11,9-2, 10-16 

nsp  10-12 

tentry 

2-7 , 10-16 

nss  1-2,2-11,3-12,3-15,3-18, 

tentry 

2-7, 10-16 

3-20,5-28,  5-29,7-l--7,3, 

t frame 

1-2,3-11,3-23,3-20,5-2 

9-4, 10-12 

5-3,5-21,7-1,7-2,9-2, 

nayl  9-4,10-13 

10-16 

ntrpt  3-14,9-4,10-13 

tinit 

2-11,6-1,9-2,  10-16 

nutype  9-4 ,10-13 

toe  2- 

11,4-5,4-9,5-22,5-31, 

[owner]  3-24--3-26 , 9-5 , 10- 1 3 

9- 

5, 10-16 

11-2 


tpd  9-2,10-16 

tvnaap  3-14,3-16,3-18,9-7,10-16 
trnreq  3- 14 , 3-16 , 3-18 , 9-7 , 1 0- 16 
trptal  3-15,5-25,9-7,10-16 
vanish  5-22,9-11,10-16 
vfeba.fO  5-33,9-12,10-17 
vfeba.f  5-33,9-12,10-17 
vfeba.npa  5-33,9-12,10-17 
vfeba.fr  5-33,9-12,10-17 
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